1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
Title: Rust 2019: how we make decisions
Category: Blog
Tags: /dev/diary, rust
Date: 2019-01-21
I'm late to the party, I know.
But writing this post took a little longer.
In fact, I wrote it three times, not really sure where I wanted it to go and what I wanted to say.
In the end, I think most things have already been said.
So this will be short.
## Problems
There have been a great number of blog posts about the problems that the Rust community is facing.
I recommend you read some of them because they're really good.
For example [boats] who published an article early december about "Organisational Dept".
Or [killercup] about how we count contributions (and other things).
Or [skade], who published a small collection of articles on organisational subjects.
[boats]: https://boats.gitlab.io/blog/post/rust-2019/
[killercup]: https://deterministic.space/rust-2019.html
[skade]: https://yakshav.es/rust-2019/
There's many more under the [#rust2019] hashtag on twitter.
[#rust2019]: https://twitter.com/search?q=%23rust2019&src=typed_query
My point is: you can read about what the issues are elsewhere, from more perspectives.
There's no point in me trying to rehash the same stuff again.
I'm not that good a writer that I will bring anything to the table that these people haven't already.
In my opinion the issues we have at the moment are because of two things.
- Teams that have too much responsibility
- Bad tools
(I won't really talk about the tools issue in this post.
In summary: the tools we use to communicate are all garbage.
And github and discourse comments are terrible for debates.
Really, any linear chat platform is terrible
- there might be another article at some point)
As I've said, there are plenty of articles that go
into _what_ is the problem with our current process.
I want to focus on the _why_, _how_ and _how we stop it_ bit of that.
And first we need to talk about how things are built.
## Vision vs Implementation
Fundamentally there are two parts to design:
**Vision** is what drives a project forward,
creating new concepts and thinking about their implications,
while **Implementation** is finding the most elegant,
sustainable and performant way of making vision a reality!
Now, these two can very often not be separated as easily as I make it out there.
Take the example of the CLI-WG.
When we first assembled earlier this year, we started working on a vision:
"how should CLI development look".
What followed then was an implementation of the vision,
as closely as we could manage with the resources and time available.
I would argue that during the implementation period of the vision,
some aspects of *what* we thought should be done
were influenced by things we learned about *how* to do them.
Like hitting a moving target.
To some extent this is how most software development works,
unless you are working towards a *very* well defined spec!
Having the same team be in charge of both the overall
vision for a system and it's implementation isn't a bad thing,
*given that the system is small enough!*
This is where teams come in!
Splitting up the community into groups of people who work on the same stuff,
in smaller numbers, so that collaboration on this scale becomes possible again.
In a way, the Rust 2018 working groups were inspired by the same idea.
The difference between teams and working groups being,
that the latter has a more loosely defined governance structure and allows people
to join and collaborate easier and more quickly.
There's less "established structure" in a working group.
These lower barriers are one of the reasons why I'm a huge fan of working groups,
and feel like the Rust project should expand on them in the future.
Maybe some teams could even be replaced.
But that's not fundamentally the issue that the project is facing.
## Blurring the lines
Problems arise when these lines are blurred too much.
This happens with both discussions, as well as to teams of people,
who get involved in too many things.
Ultimately, we need to face the fact that days are short,
people's time is limited and the number of responsibilities a single person can have
isn't infinite!
Througout previous blog posts and conversations with others,
the need or "desire" to have better communication channels has been made clear.
And I feel that we need to work on the way that we communicate,
if we are ever to fix the way that we make decisions.
But before I go into detail about what that means to _me_, specifically,
I want to talk quickly about the core team.
The core team is a medium sized group of Rust developers,
who oversee large areas of the development of Rust.
As the website puts it:
> Overall direction and policies of the project,
> subteam leadership, cross-cutting concerns.
As such, I feel it would be the perfect candidate to step back from implementation,
and focus on both vision for the entire language,
as well as communication among smaller teams.
Unfortunately this hasn't seemed to be the case in the past
and is something the core team should work on this year.
Note that I think, that this is a responsibly that should also not be taken lightly.
Most of the members of the core team are also active in other teams,
sometimes even leading them.
I feel that this is one of the reasons why this role has been neglected.
## Solutions
So I would sugest something, that I've heard others talk about before,
although rarely publicly, which might be considered a bit of a hot take.
The core team should be rotated.
What that means is that the core team in itself still exists,
does a certain number of jobs and should be considered quite a time-intensive commitment.
But the people involved in it shouldn't stay involved with it forever.
Even if it's currently (practically) already the case that the team rotates,
making this more explicit and making the roles of the core team a central part of
how other teams communicate and operate, I feel would benefit the overall
contribution climate of the rust project significantly.
Ultimately, we have a problem in how we communicate.
The lines between *vision* and *implementation* get blurred too often.
Not only in RFC discussions.
Implementation specific bikesheds on github
often result in new rationale being pushed forward,
that have nothing to do with the actual question at hand.
And as such, people often talk past each other.
I don't know how wide the communication scope of the core team should be,
but I definitely think that moving it's responsibility away from implementation
and back towards communication and fostering collaboration between teams and working groups
is the approach we will have to take this year to solve our problems of
Organisational dept!
|
