Skip to content

Commit a14f5f2

Browse files
marcoienimarcoieni
authored
Merge pull request #192 from rust-lang/planning
document planning process
2 parents fd32b02 + 5d91c90 commit a14f5f2

File tree

2 files changed

+202
-0
lines changed

2 files changed

+202
-0
lines changed

‎about/README.md‎

Lines changed: 71 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,71 @@
1+
# About
2+
3+
This document provides some information about the infrastructure team.
4+
5+
```text
6+
State of this document: Work in progress, incomplete.
7+
```
8+
9+
## Stakeholders
10+
11+
The stakeholders of the infrastructure team are:
12+
13+
- _Rust developers_: They use the infrastructure to download releases and crates
14+
and visit the Rust websites.
15+
- _rust-lang/rust contributors_:
16+
- They use the rustc CI to test their changes.
17+
- They use bors to merge their changes.
18+
- _Rust project_: They rely on the Rust infrastructure (such as bots) to
19+
improve Rust.
20+
- ..and more
21+
22+
## Values
23+
24+
We prioritize wellbeing over everything else and we want to avoid burnout at
25+
all costs.
26+
27+
## Team structure
28+
29+
The infrastructure team members are either:
30+
31+
- Full-time employees of the Rust Foundation, who are paid to work full-time
32+
on the infrastructure team.
33+
- Volunteers who contribute to the infrastructure team in their free time.
34+
35+
There might be shades of gray between these two categories, like people
36+
paid to work part-time on the infrastructure team.
37+
38+
## Goals
39+
40+
The Rust infrastructure should be:
41+
42+
- _Reliable_: The infrastructure should be accessible when needed and should
43+
work as expected.
44+
- _Secure_: It should be secure to interact with the infrastructure.
45+
- _Fast_: We want to optimize our infrastructure so that it's as fast as
46+
possible, to optimize the developer experience.
47+
- _Financially responsible_: Even though parts of the infrastructure are
48+
sponsored, we want to optimize
49+
our infrastructure so that we ask the least amount of money possible.
50+
- _Easy to maintain_: Maintaining our infrastructure should be as easy as
51+
possible. E.g.:
52+
- we want to automate as much as possible the maintenance of
53+
the infrastructure, so that maintainers can focus on more important things.
54+
- we want to refactor our code so that it's easier to read and edit.
55+
- _Easy to contribute to_: We want external contributors to be able to
56+
contribute to the infrastructure easily.
57+
58+
We have the following goals for the infrastructure team:
59+
60+
- _Sustainability_: We want to make sure that the infrastructure team is
61+
sustainable in the long term. Members of the infrastructure team should have
62+
a good time while working here.
63+
- _Growth_: We want to grow the infrastructure team, so that we can dedicate
64+
more time to the team's responsibilities.
65+
We want the Rust community to be aware of what we are working on, so that
66+
interested people can contribute to tasks they are interested in.
67+
If we manage to offer them a good experience
68+
(e.g. they work on something they enjoy, with high impact, while learning new
69+
things)
70+
they might decide to join the team and we'll have more capacity to work on
71+
more things.

‎about/planning.md‎

Lines changed: 131 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,131 @@
1+
# Infrastructure team planning
2+
3+
We (the infrastructure team) plan our work every quarter.
4+
5+
> [!NOTE]
6+
> In one year we have 4 quarters:
7+
>
8+
> - Q1: January, February, March.
9+
> - Q2: April, May, June.
10+
> - Q3: July, August, September.
11+
> - Q4: October, November, December.
12+
13+
Here's how the planning process works:
14+
15+
- At the begin of the quarter, we publish a blog post in the
16+
[Inside Rust](https://blog.rust-lang.org/inside-rust/) blog to share
17+
what we've accomplished in the last quarter and what we planned for this
18+
quarter.
19+
- During the quarter, we execute the work planned.
20+
- Before the end of the quarter, we plan the work for the next quarter.
21+
22+
Each entry in the plan has the following fields:
23+
24+
- _Owner_: the person responsible for the work.
25+
- _Tracking issue_: link to GitHub issue.
26+
- _Description_: a brief description of the work
27+
(full details should be in the GitHub issue).
28+
29+
## Are volunteers expected to own items in the plan?
30+
31+
Volunteers don't have any obligation in:
32+
33+
- Owning items in the plan.
34+
- Working on items in the plan.
35+
- Participating in the planning process.
36+
37+
However, volunteers are welcome to participate in the planning process
38+
in any way they want, including owning items in the plan.
39+
40+
See [Team structure](README.md#team-structure) for more information.
41+
42+
We want volunteers to spend their time on things they enjoy,
43+
and we acknowledge that planning might not be one of those things.
44+
45+
## How do you decide what to work on?
46+
47+
We have a wide range of responsibilities, and different
48+
[stakeholders](README.md#stakeholders), so deciding what to work on is hard.
49+
Items are selected taking into account the following criteria:
50+
51+
- _Value_: how much the work maximizes our [goals](README.md#goals).
52+
- _Effort_: how much effort is required to complete the work.
53+
- _Urgency_: how urgent is the work.
54+
55+
## Does the team only work on items in the plan?
56+
57+
No, there are:
58+
59+
- Unexpected things that come up that the team needs to work on urgently, such
60+
as incidents, security issues or high-priority requests from stakeholders.
61+
- Periodic maintenance tasks, such as updating dependencies, packages and
62+
operating systems.
63+
64+
Plus, volunteers are free to work on anything they want, although they are
65+
encouraged to work on the items that align with the team's priorities.
66+
67+
## Why do we plan?
68+
69+
Planning has the following benefits:
70+
71+
- _Transparency_: The community knows what we are working on and what to expect
72+
from us in the near future.
73+
- _Coordination_: Other teams know if a certain infra feature they are waiting
74+
for is coming soon or not. This helps them plan their work.
75+
- _Team growth_: People reading our plan might be interested in certain tasks
76+
and they might decide to help us. See our "growth" [goal](README.md#goals).
77+
The blog post will contain an explicit call to action about this.
78+
- _Prioritization_: We have limited capacity and there are many things to do.
79+
Planning helps us deciding what to work on in a more structured way, so that
80+
we don't end up working on things that are not important.
81+
- _Execution_: Planning helps us distinguish between "time to take decisions"
82+
and "time to execute". If a new big idea comes in the middle of the quarter
83+
we can easily say "cool, we'll evaluate it at the end of the quarter" and
84+
keep executing our initial plan instead of
85+
discussing if it's worth interrupting what we are doing and switch to it.
86+
Changing plans too often is not productive. If we have a clear planning, we
87+
can focus on what we need to do and avoid distractions.
88+
89+
Planning has the following drawbacks:
90+
91+
- _Pressure_: We might feel pressured to finish what we planned by the end of
92+
the quarter.
93+
However, we shouldn't. See our [Values](README.md#values).
94+
The main purpose of the plan is to give us a direction and be mindful of
95+
how we spend our time.
96+
Also, estimating is hard: if we finish 100% of what we planned, it might mean
97+
that we underestimated the work, not that we are super productive. The
98+
opposite is also true: if we finish 50% of what we planned, it might mean
99+
that we overestimated the work, not that we are not productive.
100+
Of course we should do our best to finish what we planned, but if don't, it's
101+
totally fine.
102+
The blog post should make this point clear.
103+
- _Time_: Deciding what to work on and writing it in the form of blog post
104+
takes time. However, we think this time is well spent.
105+
Also, we want to keep the planning process as lightweight as possible to avoid
106+
spending too much time on it.
107+
108+
Overall, we think that the benefits of planning outweigh the drawbacks.
109+
110+
## Why every quarter?
111+
112+
Planning too often is not productive, because it takes time.
113+
Planning too rarely doesn't allow us to adapt to changes quickly.
114+
115+
We think 3 months is the right balance.
116+
117+
## Why having a deadline?
118+
119+
We think that having a deadline (3 months in this case) helps us to:
120+
121+
- Cut scope during planning: thinking about a limited period of time, helps
122+
us stay with the feets on the ground.
123+
- Cut scope during execution: avoid spending too much time on a single item.
124+
E.g. we are at month 2 of the quarter and we still have remaining items to
125+
work on for the quarter. We can decide to cut the scope of one item
126+
(because it's in a good enough state) and move to the next one.
127+
In the next quarter we can decide if it's worth to pick up the item again and
128+
finish it.
129+
130+
We think that not having deadlines can easily lead to scope creep,
131+
i.e. we would end up working on a single item for too long.

0 commit comments

Comments
 (0)