RFC: Scaling Rust's Governance #1068

Merged
merged 3 commits into from May 7, 2015

Conversation

Projects
None yet
@aturon
Member

aturon commented Apr 17, 2015

This RFC proposes to expand, and make more explicit, Rust's governance
structure. It seeks to supplement today's core team with several
subteams that are more narrowly focused on specific areas of
interest.

Thanks to Nick Cameron, Manish Goregaokar, Yehuda Katz, Niko Matsakis
and Dave Herman for many suggestions and discussions along the way.

Rendered

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
Member

steveklabnik commented Apr 17, 2015

👍

text/0000-rust-governance.md
+## Background: today's governance structure
+
+Rust is governed by a
+[core team](https://github.com/rust-lang/rust/wiki/Note-core-team),

This comment has been minimized.

@lambda

lambda Apr 17, 2015

Contributor

Broken link, should reference the wiki backup instead.

@lambda

lambda Apr 17, 2015

Contributor

Broken link, should reference the wiki backup instead.

text/0000-rust-governance.md
+* Technical discussion should take place as much as possible on public forums,
+ ideally on RFC/PR threads and tagged discuss posts.
+
+* Each subteam will have a dedicated discuss forum tag.

This comment has been minimized.

@nagisa

nagisa Apr 17, 2015

Contributor

discuss forum should be linked to http://internals.rust-lang.org/, I guess.

@nagisa

nagisa Apr 17, 2015

Contributor

discuss forum should be linked to http://internals.rust-lang.org/, I guess.

text/0000-rust-governance.md
+* Subteams should have some kind of regular meeting or other way of making
+ decisions.
+
+* Subteams should regularly publish the status of RFCs, PRs, and other news

This comment has been minimized.

@nagisa

nagisa Apr 17, 2015

Contributor

Would be nice to have something in spirit to the homu queue.

@nagisa

nagisa Apr 17, 2015

Contributor

Would be nice to have something in spirit to the homu queue.

@nagisa

This comment has been minimized.

Show comment
Hide comment
@nagisa

nagisa Apr 17, 2015

Contributor

Is it team leader’s resposibility to select subteam members or perhaps one has to nominate oneself somehow (if so, how)?

Contributor

nagisa commented Apr 17, 2015

Is it team leader’s resposibility to select subteam members or perhaps one has to nominate oneself somehow (if so, how)?

text/0000-rust-governance.md
+
+* Each subteam will have a dedicated discuss forum tag.
+
+* Subteams should have some kind of regular meeting or other way of making

This comment has been minimized.

@Manishearth

Manishearth Apr 17, 2015

Member

Note: Probably should have public minutes as much as possible.

@Manishearth

Manishearth Apr 17, 2015

Member

Note: Probably should have public minutes as much as possible.

text/0000-rust-governance.md
+
+* Subteams should regularly publish the status of RFCs, PRs, and other news
+ related to their area.
+

This comment has been minimized.

@Manishearth

Manishearth Apr 17, 2015

Member

I think an explicit recommendation for subteams to involve people outside of the subteam in discussions/decisions whenever possible would be nice to have here. (It's probably going to happen in practice anyway)

The subteams should be viewed as place where the discussion focuses, not an authority figure that swoops in and hands out decisions.

@Manishearth

Manishearth Apr 17, 2015

Member

I think an explicit recommendation for subteams to involve people outside of the subteam in discussions/decisions whenever possible would be nice to have here. (It's probably going to happen in practice anyway)

The subteams should be viewed as place where the discussion focuses, not an authority figure that swoops in and hands out decisions.

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Apr 17, 2015

Member

@nagisa

Is it team leader’s resposibility to select subteam members or perhaps one has to nominate oneself somehow (if so, how)?

The team will select new members. This can either be unilaterally by the team owner, or by a discussion amongst the other members, if any. Should be the latter in general, though I think the RfC leaves the decision of how subteams can be expanded to the individual subteams so a subteam might decide on a more involved process.

Of course, you can nominate yourself by asking the team leader 😛

Member

Manishearth commented Apr 17, 2015

@nagisa

Is it team leader’s resposibility to select subteam members or perhaps one has to nominate oneself somehow (if so, how)?

The team will select new members. This can either be unilaterally by the team owner, or by a discussion amongst the other members, if any. Should be the latter in general, though I think the RfC leaves the decision of how subteams can be expanded to the individual subteams so a subteam might decide on a more involved process.

Of course, you can nominate yourself by asking the team leader 😛

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Apr 17, 2015

Member

@nagisa @lambda I've taken your suggestions, thanks! And @nagisa, I added a bit of text about how the subteam membership evolves. Basically the policy is left to each subteam to decide (since the needs will differ by area), but after the team is up and running changes to its makeup should involve some kind of team consensus.

Member

aturon commented Apr 17, 2015

@nagisa @lambda I've taken your suggestions, thanks! And @nagisa, I added a bit of text about how the subteam membership evolves. Basically the policy is left to each subteam to decide (since the needs will differ by area), but after the team is up and running changes to its makeup should involve some kind of team consensus.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Apr 17, 2015

Member

@Manishearth: I've pushed a commit to address both of the points you raised. Thanks!

Member

aturon commented Apr 17, 2015

@Manishearth: I've pushed a commit to address both of the points you raised. Thanks!

+* Setting up the subteam:
+
+ * Deciding on the initial membership of the subteam (in consultation with
+ the core team). Once the subteam is up and running.

This comment has been minimized.

@Gankro

Gankro Apr 17, 2015

Contributor

Once the subteam is up and running.

? Missing a word or extra punctuation or something?

@Gankro

Gankro Apr 17, 2015

Contributor

Once the subteam is up and running.

? Missing a word or extra punctuation or something?

@Gankro

This comment has been minimized.

Show comment
Hide comment
@Gankro

Gankro Apr 17, 2015

Contributor

Overall this seems like a major improvement to the current process, 👍.

All of my thoughts/concerns are basically things that can/should be hashed out adhoc by the individual teams, I think.

Contributor

Gankro commented Apr 17, 2015

Overall this seems like a major improvement to the current process, 👍.

All of my thoughts/concerns are basically things that can/should be hashed out adhoc by the individual teams, I think.

@reem

This comment has been minimized.

Show comment
Hide comment
@reem

reem Apr 18, 2015

👍 from me too, this seems really nice.

reem commented Apr 18, 2015

👍 from me too, this seems really nice.

+ never. Recent blog posts about the 1.0 release and stabilization
+ have made a big step in this direction. After 1.0, as part of the
+ regular release process, we'll want to find some regular cadence for
+ setting and communicating priorities.

This comment has been minimized.

@nrc

nrc Apr 20, 2015

Member

For a project to be truly open, the process on deciding on these priorities must be public as well as the outcomes. Blog posts etc. have a place in keeping casual users informed, but to truly involve the community, we need to do much better at sharing how the core team arrive at decisions and trade-offs.

I.e., we need to find ways for the community to be part of the process (even if that is just as observers), not just recipients of the outcomes.

@nrc

nrc Apr 20, 2015

Member

For a project to be truly open, the process on deciding on these priorities must be public as well as the outcomes. Blog posts etc. have a place in keeping casual users informed, but to truly involve the community, we need to do much better at sharing how the core team arrive at decisions and trade-offs.

I.e., we need to find ways for the community to be part of the process (even if that is just as observers), not just recipients of the outcomes.

This comment has been minimized.

@wycats

wycats Apr 20, 2015

Contributor

Do you feel the RFC process is deficient in some way with regard to this?

@wycats

wycats Apr 20, 2015

Contributor

Do you feel the RFC process is deficient in some way with regard to this?

This comment has been minimized.

@nrc

nrc Apr 20, 2015

Member

The process of setting priorities and strategic level direction has not been part of the RFC process, its been decided by the core team and only the results of the process have been stated publicly (not even the results sometimes). So it seems to be a process which is (somewhat) orthogonal to the RFC process and one where the level of openness has been sub-optimal.

@nrc

nrc Apr 20, 2015

Member

The process of setting priorities and strategic level direction has not been part of the RFC process, its been decided by the core team and only the results of the process have been stated publicly (not even the results sometimes). So it seems to be a process which is (somewhat) orthogonal to the RFC process and one where the level of openness has been sub-optimal.

This comment has been minimized.

@glaebhoerl

glaebhoerl Apr 20, 2015

Contributor

👍

@glaebhoerl

glaebhoerl Apr 20, 2015

Contributor

👍

This comment has been minimized.

@aturon

aturon Apr 21, 2015

Member

Niko's recent post about post-1.0 priorities is a good example of the kind of communication I have in mind here. The initial priorities laid out came out of consultation with a large number of people in the community, and the post itself is an explicit "request for comments". I'll make some additional replies about core team communication elsewhere on thread.

@aturon

aturon Apr 21, 2015

Member

Niko's recent post about post-1.0 priorities is a good example of the kind of communication I have in mind here. The initial priorities laid out came out of consultation with a large number of people in the community, and the post itself is an explicit "request for comments". I'll make some additional replies about core team communication elsewhere on thread.

+ decisions. The content of this meeting should be summarized with the rationale
+ for each decision -- and, as explained below, decisions should generally be
+ about weighting a set of already-known tradeoffs, not discussing or
+ discovering new rationale.

This comment has been minimized.

@nrc

nrc Apr 20, 2015

Member

Can we mandate that any meetings should be minuted? And that as much communication as possible should be public - i.e., using publicly archived mailing lists or discuss vs private email and using a public irc channel rather than private messaging.

@nrc

nrc Apr 20, 2015

Member

Can we mandate that any meetings should be minuted? And that as much communication as possible should be public - i.e., using publicly archived mailing lists or discuss vs private email and using a public irc channel rather than private messaging.

This comment has been minimized.

@wycats

wycats Apr 20, 2015

Contributor

That seems totally reasonable. It should be added to the doc.

@wycats

wycats Apr 20, 2015

Contributor

That seems totally reasonable. It should be added to the doc.

This comment has been minimized.

@reem

reem Apr 20, 2015

A public IRC channel for each subteam with logging sounds ideal.

@reem

reem Apr 20, 2015

A public IRC channel for each subteam with logging sounds ideal.

This comment has been minimized.

@Manishearth

Manishearth Apr 20, 2015

Member

This sounds good, but for the moderation subteam we might want to allow them to discuss things in private, though general communication should be public as much as possible. With the mod subteam there's going to be a lot of discussion of people, and this should be kept private so that the team members can be open about it and so that there's no chance of a user feeling publicly humiliated. Bans and all are a way to let the user cool off and reevaluate their reasons for being here and their behavior -- public discussion behind a ban can lead to a permanent-ish record which we may not want.

@Manishearth

Manishearth Apr 20, 2015

Member

This sounds good, but for the moderation subteam we might want to allow them to discuss things in private, though general communication should be public as much as possible. With the mod subteam there's going to be a lot of discussion of people, and this should be kept private so that the team members can be open about it and so that there's no chance of a user feeling publicly humiliated. Bans and all are a way to let the user cool off and reevaluate their reasons for being here and their behavior -- public discussion behind a ban can lead to a permanent-ish record which we may not want.

This comment has been minimized.

This comment has been minimized.

@aturon

aturon Apr 21, 2015

Member

Note the bullet in the RFC:

Technical discussion should take place as much as possible on public forums, ideally on RFC/PR threads and tagged discuss posts.

I'll supplement this by introducing public, logged IRC channels as well. There are several existing channels that can be repurposed for this role.

Also, I personally don't think that literal transcripts of meetings are always so valuable -- they are often inaccurate, and take one person out of the conversation, and can be very hard to decipher. I think it would be much better to instead coherently summarize what was said and done in any meetings -- the traditional notion of "minutes".

In my experience meetings are actually a poor place to make decisions -- it's easy to be swayed by the "heat of the moment" and a sense that an opinion needs to be registered immediately. It works much better to log objections directly onto RFC threads, and then follow up as those objections are addressed.

In the core team, for example, we almost never make decisions on RFCs in a meeting; at most, we call attention to RFCs that need decisions soon. Instead, we keep track of RFCs nearing decision point (a bit like the "final comment period"), and make sure that people who have objections have raised them publicly on thread. I would suggest a similar process for subteams.

As an aside, I think private conversation has its place. It allows for greater bandwidth (due to shared context), greater candor, and makes it easier to hash out ideas in an earlier phase, and so on. I do not think it's possible or desirable to legislate away its existence.

Rather, there needs to be a culture of public communication:

  • As soon as an opinion or idea becomes relatively formed -- ready for public consumption -- go public with it. Whenever practical, start in public.
  • All decisions are made based on previously-discussed public rationale.
  • Use of processes like RFCs to move things forward in a very public, visible way.

All of this is already in the RFC.

@aturon

aturon Apr 21, 2015

Member

Note the bullet in the RFC:

Technical discussion should take place as much as possible on public forums, ideally on RFC/PR threads and tagged discuss posts.

I'll supplement this by introducing public, logged IRC channels as well. There are several existing channels that can be repurposed for this role.

Also, I personally don't think that literal transcripts of meetings are always so valuable -- they are often inaccurate, and take one person out of the conversation, and can be very hard to decipher. I think it would be much better to instead coherently summarize what was said and done in any meetings -- the traditional notion of "minutes".

In my experience meetings are actually a poor place to make decisions -- it's easy to be swayed by the "heat of the moment" and a sense that an opinion needs to be registered immediately. It works much better to log objections directly onto RFC threads, and then follow up as those objections are addressed.

In the core team, for example, we almost never make decisions on RFCs in a meeting; at most, we call attention to RFCs that need decisions soon. Instead, we keep track of RFCs nearing decision point (a bit like the "final comment period"), and make sure that people who have objections have raised them publicly on thread. I would suggest a similar process for subteams.

As an aside, I think private conversation has its place. It allows for greater bandwidth (due to shared context), greater candor, and makes it easier to hash out ideas in an earlier phase, and so on. I do not think it's possible or desirable to legislate away its existence.

Rather, there needs to be a culture of public communication:

  • As soon as an opinion or idea becomes relatively formed -- ready for public consumption -- go public with it. Whenever practical, start in public.
  • All decisions are made based on previously-discussed public rationale.
  • Use of processes like RFCs to move things forward in a very public, visible way.

All of this is already in the RFC.

This comment has been minimized.

@nrc

nrc Apr 21, 2015

Member

I think there is some happy place between summaries and literal transcripts that is more ideal than both. I often find detailed minutes extremely useful. Specifically it is good to know who is involved in a discussion and how (so you know who to contact if you want to be part of the conversation), how much confidence there was in the arguments, how close the decision was, what the motivations are, the reasoning that people use. Summaries rarely capture the level of detail necessary for someone not at the meeting to really understand how a decision is made.

I do agree there is a place for private conversation, but it should be much rarer then it currently is. It has its place to do very early brainstorming and later very detailed work, but we would benefit from more of the middle section of idea development being public by default.

In particular, the idea of forming an idea in private and then communicating it publicly seems the wrong approach. The idea should be formed in public (where by public I don't mean the whole world or every Rust user, it might mean just one subteam's peers) and there should be no need to communicate things because the conversation itself is public.

@nrc

nrc Apr 21, 2015

Member

I think there is some happy place between summaries and literal transcripts that is more ideal than both. I often find detailed minutes extremely useful. Specifically it is good to know who is involved in a discussion and how (so you know who to contact if you want to be part of the conversation), how much confidence there was in the arguments, how close the decision was, what the motivations are, the reasoning that people use. Summaries rarely capture the level of detail necessary for someone not at the meeting to really understand how a decision is made.

I do agree there is a place for private conversation, but it should be much rarer then it currently is. It has its place to do very early brainstorming and later very detailed work, but we would benefit from more of the middle section of idea development being public by default.

In particular, the idea of forming an idea in private and then communicating it publicly seems the wrong approach. The idea should be formed in public (where by public I don't mean the whole world or every Rust user, it might mean just one subteam's peers) and there should be no need to communicate things because the conversation itself is public.

This comment has been minimized.

@aturon

aturon Apr 21, 2015

Member

@nrc

I think there is some happy place between summaries and literal transcripts that is more ideal than both. I often find detailed minutes extremely useful. Specifically it is good to know who is involved in a discussion and how (so you know who to contact if you want to be part of the conversation), how much confidence there was in the arguments, how close the decision was, what the motivations are, the reasoning that people use. Summaries rarely capture the level of detail necessary for someone not at the meeting to really understand how a decision is made.

This puts much more weight on meetings/final point of making a decision than I think it merits.

We've been pushing for the last several months for strong, active participation on RFC threads prior to any decision. The decision-making process at this point is usually just a check: "Has everyone's objections been raised on the thread and responded to"? And the more controversial a topic, the more we strive to debate it vigorously on the RFC thread.

When RFC decisions were previously made in the minuted weekly meeting, there were many problematic cases that resulted in a lot of frustration in the community, despite those minutes.

I think that the situation has improved greatly over the last several months, mostly due to the increased discipline in the core team spending time engaging directly on RFC threads, laying out arguments, tradeoffs, and worries. These activities all support the goals you mentioned above, but they do so before the point of a final decision, and I think that is key.

Whatever venue a decision is made within, I think what people want is a chance to engage with the rationale, and thereby to influence the decision-makers, prior to the final decision. That's not really about meetings or minutes; it's about team members participating actively in all phases of the RFC process.

I do agree there is a place for private conversation, but it should be much rarer then it currently is. It has its place to do very early brainstorming and later very detailed work, but we would benefit from more of the middle section of idea development being public by default.

I think everyone agrees that conversation should be public by default, and the RFC explicitly mentions this (as did my bullets above).

FWIW, I don't share the impression that much of significance is being discussed privately at the moment. I tried to express this above with the strong move toward participation on RFC threads, which I think has been very successful. It also applies to topics beyond RFC decisions, where anything actionable that comes out of a core team meeting has a next step of getting feedback from the broader community, be it via a discourse thread, a new RFC, or something else.

But in any case, as I've said elsewhere, we can certainly minute the core team meetings (in the traditional sense) going forward.

In particular, the idea of forming an idea in private and then communicating it publicly seems the wrong approach. The idea should be formed in public (where by public I don't mean the whole world or every Rust user, it might mean just one subteam's peers) and there should be no need to communicate things because the conversation itself is public.

This may just be a difference in working style. I appreciate being able to bounce a passing thought off a collaborator without starting an entire thread or group IRC discussion about it. If it turns into something interesting, then I get feedback from a larger group until I'm ready to write an actual RFC about it.

@aturon

aturon Apr 21, 2015

Member

@nrc

I think there is some happy place between summaries and literal transcripts that is more ideal than both. I often find detailed minutes extremely useful. Specifically it is good to know who is involved in a discussion and how (so you know who to contact if you want to be part of the conversation), how much confidence there was in the arguments, how close the decision was, what the motivations are, the reasoning that people use. Summaries rarely capture the level of detail necessary for someone not at the meeting to really understand how a decision is made.

This puts much more weight on meetings/final point of making a decision than I think it merits.

We've been pushing for the last several months for strong, active participation on RFC threads prior to any decision. The decision-making process at this point is usually just a check: "Has everyone's objections been raised on the thread and responded to"? And the more controversial a topic, the more we strive to debate it vigorously on the RFC thread.

When RFC decisions were previously made in the minuted weekly meeting, there were many problematic cases that resulted in a lot of frustration in the community, despite those minutes.

I think that the situation has improved greatly over the last several months, mostly due to the increased discipline in the core team spending time engaging directly on RFC threads, laying out arguments, tradeoffs, and worries. These activities all support the goals you mentioned above, but they do so before the point of a final decision, and I think that is key.

Whatever venue a decision is made within, I think what people want is a chance to engage with the rationale, and thereby to influence the decision-makers, prior to the final decision. That's not really about meetings or minutes; it's about team members participating actively in all phases of the RFC process.

I do agree there is a place for private conversation, but it should be much rarer then it currently is. It has its place to do very early brainstorming and later very detailed work, but we would benefit from more of the middle section of idea development being public by default.

I think everyone agrees that conversation should be public by default, and the RFC explicitly mentions this (as did my bullets above).

FWIW, I don't share the impression that much of significance is being discussed privately at the moment. I tried to express this above with the strong move toward participation on RFC threads, which I think has been very successful. It also applies to topics beyond RFC decisions, where anything actionable that comes out of a core team meeting has a next step of getting feedback from the broader community, be it via a discourse thread, a new RFC, or something else.

But in any case, as I've said elsewhere, we can certainly minute the core team meetings (in the traditional sense) going forward.

In particular, the idea of forming an idea in private and then communicating it publicly seems the wrong approach. The idea should be formed in public (where by public I don't mean the whole world or every Rust user, it might mean just one subteam's peers) and there should be no need to communicate things because the conversation itself is public.

This may just be a difference in working style. I appreciate being able to bounce a passing thought off a collaborator without starting an entire thread or group IRC discussion about it. If it turns into something interesting, then I get feedback from a larger group until I'm ready to write an actual RFC about it.

This comment has been minimized.

@nrc

nrc Apr 23, 2015

Member

I think we are more or less in agreement, with perhaps some difference of opinion about where to draw the line in the details.

I hope that having the subteams will make things easier. Rather than bouncing ideas off a specific person, we have a small group of people to ask if they're interested in the 'idea bouncing stage', and that group of people at least can know which ideas are bouncing around.

@nrc

nrc Apr 23, 2015

Member

I think we are more or less in agreement, with perhaps some difference of opinion about where to draw the line in the details.

I hope that having the subteams will make things easier. Rather than bouncing ideas off a specific person, we have a small group of people to ask if they're interested in the 'idea bouncing stage', and that group of people at least can know which ideas are bouncing around.

+subteam should set an explicit policy about:
+
+1. What requires an RFC for the subteam's area, and
+2. What the non-RFC review process is.

This comment has been minimized.

@nrc

nrc Apr 20, 2015

Member

At the least it seems that each subteam should have a way to broadcast changes which are major enough to make them nervous, but not major enough to need an RFC - an 'intent to implement' email or something.

@nrc

nrc Apr 20, 2015

Member

At the least it seems that each subteam should have a way to broadcast changes which are major enough to make them nervous, but not major enough to need an RFC - an 'intent to implement' email or something.

+Finally, the moderation team is responsible for dealing with CoC violations.
+
+One key difference from the other subteams is that the moderation team does not
+have a leader. Its members are chosen directly by the core team, and should be

This comment has been minimized.

@nrc

nrc Apr 20, 2015

Member

I've previously suggested that this team should in some way 'choose itself' rather than be appointed by the core team. That probably still requires one or two appointments, but the rest can be bootstrapped.

@nrc

nrc Apr 20, 2015

Member

I've previously suggested that this team should in some way 'choose itself' rather than be appointed by the core team. That probably still requires one or two appointments, but the rest can be bootstrapped.

+have a leader. Its members are chosen directly by the core team, and should be
+community members who have demonstrated the highest standard of discourse and
+maturity. To limit conflicts of interest, **the moderation subteam should not
+include any core team members**. However, the subteam is free to consult with

This comment has been minimized.

@nrc

nrc Apr 20, 2015

Member

For clarity, are non-core-team Mozilla employees/contractors/interns/former interns also excluded or fair game for the moderation subteam?

@nrc

nrc Apr 20, 2015

Member

For clarity, are non-core-team Mozilla employees/contractors/interns/former interns also excluded or fair game for the moderation subteam?

This comment has been minimized.

@wycats

wycats Apr 20, 2015

Contributor

I'm personally pretty uneasy with the idea of making Mozilla special from the perspective of governance rules, especially since I expect that, in the long term, more and more companies and individuals will come to be represented on the core team and in subteams.

That said, if the intent of some part of the process is to ensure fair dealing (and the perception of fair dealing), we should be cognizant that companies with significant representation on the core team will be a poor fit.

@wycats

wycats Apr 20, 2015

Contributor

I'm personally pretty uneasy with the idea of making Mozilla special from the perspective of governance rules, especially since I expect that, in the long term, more and more companies and individuals will come to be represented on the core team and in subteams.

That said, if the intent of some part of the process is to ensure fair dealing (and the perception of fair dealing), we should be cognizant that companies with significant representation on the core team will be a poor fit.

This comment has been minimized.

@nrc

nrc Apr 20, 2015

Member

There has been a lot of confusion in the past between the set of core team members and the set of people affiliated with Mozilla in some way. I agree that this will become less significant with time, but here and now I think it is worth clarifying.

@nrc

nrc Apr 20, 2015

Member

There has been a lot of confusion in the past between the set of core team members and the set of people affiliated with Mozilla in some way. I agree that this will become less significant with time, but here and now I think it is worth clarifying.

This comment has been minimized.

@Manishearth

Manishearth Apr 20, 2015

Member

I think mentioning that the mod subteam should not include core team members is enough for the scope of this RfC; subteam can internally decide how to pick users beyond that. I would suggest that they avoid current employees though (at least for now), since at the moment there is a strong core-team/Mozilla relation and conflict of interest is possible.

@Manishearth

Manishearth Apr 20, 2015

Member

I think mentioning that the mod subteam should not include core team members is enough for the scope of this RfC; subteam can internally decide how to pick users beyond that. I would suggest that they avoid current employees though (at least for now), since at the moment there is a strong core-team/Mozilla relation and conflict of interest is possible.

+
+In general, moderators can and should unilaterally take the first step, but
+steps beyond that (particularly banning) should be done via consensus with the
+other moderators. Permanent bans require core team approval.

This comment has been minimized.

@nrc

nrc Apr 20, 2015

Member

It seems like unnecessary oversight to require core-team approval here. It seems to me that this breaks the separation of concerns between the two groups (to give a political equivalent, government does not need to approve life sentences - the judiciary are considered independent in that respect).

Put another way, since every permanent ban must be approved by the core-team, it means that all bans are political rather than judicial.

@nrc

nrc Apr 20, 2015

Member

It seems like unnecessary oversight to require core-team approval here. It seems to me that this breaks the separation of concerns between the two groups (to give a political equivalent, government does not need to approve life sentences - the judiciary are considered independent in that respect).

Put another way, since every permanent ban must be approved by the core-team, it means that all bans are political rather than judicial.

This comment has been minimized.

@tshepang

tshepang Apr 20, 2015

Contributor

👍 the sentence should be removed. I did wonder what the motivation behind it is.

@tshepang

tshepang Apr 20, 2015

Contributor

👍 the sentence should be removed. I did wonder what the motivation behind it is.

This comment has been minimized.

@aturon

aturon Apr 21, 2015

Member

The motivation, as with the feature-gate removal, is to provide an extra level of checking before making the final step. Like gate removal, it should basically always be approved; if it's not, something has gone very wrong.

I don't believe we should strive for a complete "separation of concerns" between any of the teams; the goal here is greater scalability, and having teams with different (but overlapping) focuses can get us a long way, in my opinion.

I certainly hope that bans aren't common enough to cause scalability issues, and I think getting some additional opinions from the core team before kicking someone permanently out of the community is a reasonable protection against moderation going overboard.

In terms of governmental analogies -- which I'm wary of for many reasons -- many governments set up an elaborate, explicit interconnectedness between various branches. In the US, for example, there's the presidential veto of legislation, but likewise the legislation's requirement to "confirm" the president's choices of e.g. cabinet members. Etc. etc.

@aturon

aturon Apr 21, 2015

Member

The motivation, as with the feature-gate removal, is to provide an extra level of checking before making the final step. Like gate removal, it should basically always be approved; if it's not, something has gone very wrong.

I don't believe we should strive for a complete "separation of concerns" between any of the teams; the goal here is greater scalability, and having teams with different (but overlapping) focuses can get us a long way, in my opinion.

I certainly hope that bans aren't common enough to cause scalability issues, and I think getting some additional opinions from the core team before kicking someone permanently out of the community is a reasonable protection against moderation going overboard.

In terms of governmental analogies -- which I'm wary of for many reasons -- many governments set up an elaborate, explicit interconnectedness between various branches. In the US, for example, there's the presidential veto of legislation, but likewise the legislation's requirement to "confirm" the president's choices of e.g. cabinet members. Etc. etc.

This comment has been minimized.

@nrc

nrc Apr 21, 2015

Member

If part of the reason for having a moderation team is to avoid conflict of interest, it seems you can't have this check - it's clearly a conflict of interest. I realise in purely practical terms this is not a big deal, but appearance is very important, and this creates a bad appearance. In particular, this means that the core team are essentially exempt from being banned and, a cynical person could argue, from the CoC itself.

A ban is not a death penalty - it can always be fixed afterwards so there is plenty of opportunity for the core team to work with the moderation team if a mistake is made and to fix the mistake. It seems overly cautious to have this check - the expense of the paranoia about the moderation team going overboard (which seems unlikely) is the perception of corruption.

We should trust out moderation team by default, if they turn out to be terrible then I believe we have the ability and community will to fix things at that point rather than trying to plan in advance.

@nrc

nrc Apr 21, 2015

Member

If part of the reason for having a moderation team is to avoid conflict of interest, it seems you can't have this check - it's clearly a conflict of interest. I realise in purely practical terms this is not a big deal, but appearance is very important, and this creates a bad appearance. In particular, this means that the core team are essentially exempt from being banned and, a cynical person could argue, from the CoC itself.

A ban is not a death penalty - it can always be fixed afterwards so there is plenty of opportunity for the core team to work with the moderation team if a mistake is made and to fix the mistake. It seems overly cautious to have this check - the expense of the paranoia about the moderation team going overboard (which seems unlikely) is the perception of corruption.

We should trust out moderation team by default, if they turn out to be terrible then I believe we have the ability and community will to fix things at that point rather than trying to plan in advance.

This comment has been minimized.

@aturon

aturon Apr 21, 2015

Member

@nrc

(text re-ordered a bit)

If part of the reason for having a moderation team is to avoid conflict of interest, it seems you can't have this check - it's clearly a conflict of interest. I realise in purely practical terms this is not a big deal, but appearance is very important, and this creates a bad appearance. In particular, this means that the core team are essentially exempt from being banned and, a cynical person could argue, from the CoC itself.

We should trust out moderation team by default, if they turn out to be terrible then I believe we have the ability and community will to fix things at that point rather than trying to plan in advance.

I don't believe that conflicts of interest or trust are such binary things. This RFC gives a huge amount of trust to subteams, allowing them to accept, reject, and implement RFCs independently, and even to set the policy about what requires an RFC in their area. Likewise, the majority of the moderation subteam's activities are done without oversight, including temporary bans.

Similarly, prohibiting core team members from sitting on the moderation team substantially decreases the potential for conflicts of interest -- the most important of which, historically, is not the claim that the core team is breaking the CoC but rather that any attempts to enforce it are actually about squelching dissent on technical topics.

In short, I object to the idea that having any amount of oversight indicates a default of mistrust, or that any potential for conflicts of interest indicates that moderation is a sham. It is all a spectrum, and I believe that this RFC moves control to a substantial degree away from the core team, keeping around only final gatekeeping checks at the final stage. It is for catching mistakes in the process that potentially have significant consequences.

A ban is not a death penalty - it can always be fixed afterwards so there is plenty of opportunity for the core team to work with the moderation team if a mistake is made and to fix the mistake. It seems overly cautious to have this check - the expense of the paranoia about the moderation team going overboard (which seems unlikely) is the perception of corruption.

A ban might be reversible, but the fallout from making a ban, and then reversing it, could be extreme. Much better to avoid the mistake in the first place.

As I said above, the worry about conflicts of interest that I've encountered has wholly been about the other side -- that if the core team enforced the CoC, it could be seen as doing so to silence technical dissent.

@aturon

aturon Apr 21, 2015

Member

@nrc

(text re-ordered a bit)

If part of the reason for having a moderation team is to avoid conflict of interest, it seems you can't have this check - it's clearly a conflict of interest. I realise in purely practical terms this is not a big deal, but appearance is very important, and this creates a bad appearance. In particular, this means that the core team are essentially exempt from being banned and, a cynical person could argue, from the CoC itself.

We should trust out moderation team by default, if they turn out to be terrible then I believe we have the ability and community will to fix things at that point rather than trying to plan in advance.

I don't believe that conflicts of interest or trust are such binary things. This RFC gives a huge amount of trust to subteams, allowing them to accept, reject, and implement RFCs independently, and even to set the policy about what requires an RFC in their area. Likewise, the majority of the moderation subteam's activities are done without oversight, including temporary bans.

Similarly, prohibiting core team members from sitting on the moderation team substantially decreases the potential for conflicts of interest -- the most important of which, historically, is not the claim that the core team is breaking the CoC but rather that any attempts to enforce it are actually about squelching dissent on technical topics.

In short, I object to the idea that having any amount of oversight indicates a default of mistrust, or that any potential for conflicts of interest indicates that moderation is a sham. It is all a spectrum, and I believe that this RFC moves control to a substantial degree away from the core team, keeping around only final gatekeeping checks at the final stage. It is for catching mistakes in the process that potentially have significant consequences.

A ban is not a death penalty - it can always be fixed afterwards so there is plenty of opportunity for the core team to work with the moderation team if a mistake is made and to fix the mistake. It seems overly cautious to have this check - the expense of the paranoia about the moderation team going overboard (which seems unlikely) is the perception of corruption.

A ban might be reversible, but the fallout from making a ban, and then reversing it, could be extreme. Much better to avoid the mistake in the first place.

As I said above, the worry about conflicts of interest that I've encountered has wholly been about the other side -- that if the core team enforced the CoC, it could be seen as doing so to silence technical dissent.

This comment has been minimized.

@Manishearth

Manishearth Apr 22, 2015

Member
  • the most important of which, historically, is not the claim that the core team is breaking the CoC but rather that any attempts to enforce it are actually about squelching dissent on technical topics.

FWIW this is the situation I was considering when I noted that we should avoid Mozilla employees (/core team members) in the original CoC enforcement proposal. I did not think we would need to plan for a CT member violating the CoC, nor would we have to plan for the community being wary of the same. I still don't think we need to. I'm more wary of a perception of the core team squelching dissent, as you said.

A ban might be reversible, but the fallout from making a ban, and then reversing it, could be extreme. Much better to avoid the mistake in the first place.

Huge +1 here. Bans can easily antagonize the recipient (that's why we try to resolve it without a ban first), make people feel patronized, and in general sour a situation further.

However, note that in most cases with bans time is of the essence. Given that the core team is concentrated on one hemisphere, waiting for CT approval on something might take a day -- bear in mind that it probably already took half a day for the mod team to discuss this out. This is a lot of time to wait if there's a fight brewing or something. I'm not so concerned about a perception of corruption due to this as I am concerned of the time lost in the process.

So it might be okay to be looser on the core team approval thing for a certain degree of severity.

Though the time thing becomes a non-issue if, after the first or second infraction by someone, the mod team and perhaps a core team member discuss it out internally and decide what to do the next time an infraction of the same type comes from that person, if ever. If there doesn't seem to be any disagreement, if the person violates the CoC again, a mod can just unilaterally-ish hand out a ban the next time. (In cases where the pre-discussion isn't unanimous, it might be best to discuss it out)

@Manishearth

Manishearth Apr 22, 2015

Member
  • the most important of which, historically, is not the claim that the core team is breaking the CoC but rather that any attempts to enforce it are actually about squelching dissent on technical topics.

FWIW this is the situation I was considering when I noted that we should avoid Mozilla employees (/core team members) in the original CoC enforcement proposal. I did not think we would need to plan for a CT member violating the CoC, nor would we have to plan for the community being wary of the same. I still don't think we need to. I'm more wary of a perception of the core team squelching dissent, as you said.

A ban might be reversible, but the fallout from making a ban, and then reversing it, could be extreme. Much better to avoid the mistake in the first place.

Huge +1 here. Bans can easily antagonize the recipient (that's why we try to resolve it without a ban first), make people feel patronized, and in general sour a situation further.

However, note that in most cases with bans time is of the essence. Given that the core team is concentrated on one hemisphere, waiting for CT approval on something might take a day -- bear in mind that it probably already took half a day for the mod team to discuss this out. This is a lot of time to wait if there's a fight brewing or something. I'm not so concerned about a perception of corruption due to this as I am concerned of the time lost in the process.

So it might be okay to be looser on the core team approval thing for a certain degree of severity.

Though the time thing becomes a non-issue if, after the first or second infraction by someone, the mod team and perhaps a core team member discuss it out internally and decide what to do the next time an infraction of the same type comes from that person, if ever. If there doesn't seem to be any disagreement, if the person violates the CoC again, a mod can just unilaterally-ish hand out a ban the next time. (In cases where the pre-discussion isn't unanimous, it might be best to discuss it out)

This comment has been minimized.

@aturon

aturon Apr 22, 2015

Member

@Manishearth

However, note that in most cases with bans time is of the essence. Given that the core team is concentrated on one hemisphere, waiting for CT approval on something might take a day -- bear in mind that it probably already took half a day for the mod team to discuss this out. This is a lot of time to wait if there's a fight brewing or something. I'm not so concerned about a perception of corruption due to this as I am concerned of the time lost in the process.

I think you say this in the rest of your comment, but just to be clear: it's worth remembering that this is only about permanent bans. The moderation team is free to issue short-term bans on its own (and in truly urgent cases, an individual moderator could do so unilaterally). That should take care of any latency issue, and give plenty of time for discussion with both teams before deciding if/when to issue a permanent ban.

@aturon

aturon Apr 22, 2015

Member

@Manishearth

However, note that in most cases with bans time is of the essence. Given that the core team is concentrated on one hemisphere, waiting for CT approval on something might take a day -- bear in mind that it probably already took half a day for the mod team to discuss this out. This is a lot of time to wait if there's a fight brewing or something. I'm not so concerned about a perception of corruption due to this as I am concerned of the time lost in the process.

I think you say this in the rest of your comment, but just to be clear: it's worth remembering that this is only about permanent bans. The moderation team is free to issue short-term bans on its own (and in truly urgent cases, an individual moderator could do so unilaterally). That should take care of any latency issue, and give plenty of time for discussion with both teams before deciding if/when to issue a permanent ban.

This comment has been minimized.

@Manishearth

Manishearth Apr 22, 2015

Member

Oh, I didn't realize that.

This works.

And I think this should address @nrc's concerns too, since permabans should be very rare anyway.

@Manishearth

Manishearth Apr 22, 2015

Member

Oh, I didn't realize that.

This works.

And I think this should address @nrc's concerns too, since permabans should be very rare anyway.

This comment has been minimized.

@nrc

nrc Apr 23, 2015

Member

I did realise it was only permanent bans. I agree they ought to be rare and that is one reason I'm more keen to sort things out ahead of time, whereas for other things I think 'see how it goes' is a better approach. I worry that in the past the core team and core team + extras have been very hesitant around bans, when in retrospect they should have been handed out earlier. This extra check seems like it will encourage such hesitancy in the future too - more steps to go through and more people to debate means more chance of indecision. Hopefully, it will be rare enough to not matter....

@nrc

nrc Apr 23, 2015

Member

I did realise it was only permanent bans. I agree they ought to be rare and that is one reason I'm more keen to sort things out ahead of time, whereas for other things I think 'see how it goes' is a better approach. I worry that in the past the core team and core team + extras have been very hesitant around bans, when in retrospect they should have been handed out earlier. This extra check seems like it will encourage such hesitancy in the future too - more steps to go through and more people to debate means more chance of indecision. Hopefully, it will be rare enough to not matter....

+themselves from moderation in threads where they are actively participating in
+the technical debate or otherwise have a conflict of interest. Moderators who
+fail to keep up this standard, or who abuse the moderation process, may be
+removed by the core team.

This comment has been minimized.

@nrc

nrc Apr 20, 2015

Member

Does the moderation team also have the power to remove one of its own members? (presumably by consensus of the others)

@nrc

nrc Apr 20, 2015

Member

Does the moderation team also have the power to remove one of its own members? (presumably by consensus of the others)

This comment has been minimized.

@Manishearth

Manishearth Apr 20, 2015

Member

This probably can be decided by the mod team itself once formed.

I would say yes.

@Manishearth

Manishearth Apr 20, 2015

Member

This probably can be decided by the mod team itself once formed.

I would say yes.

+One possibility is that decentralized decisions may lead to a lack of coherence
+in the overall design of Rust. However, the existence of the core team -- and
+the fact that subteam leaders will thus remain in close communication on
+cross-cutting concerns in particular -- serves to greatly mitigate that risk.

This comment has been minimized.

@nrc

nrc Apr 20, 2015

Member

Worth pointing out that we expect core-team members to be subteam members (not just the leader) and this is also a mitigating factor.

@nrc

nrc Apr 20, 2015

Member

Worth pointing out that we expect core-team members to be subteam members (not just the leader) and this is also a mitigating factor.

+cross-cutting concerns in particular -- serves to greatly mitigate that risk.
+
+As with any change to governance, there is risk that this RFC would harm
+processes that are working well. In particular, bringing on a large number of

This comment has been minimized.

@nrc

nrc Apr 20, 2015

Member

"large number" is scary here - I hope the absorption of new people into decision making roles is slow and gradual. It might be worth being explicit in this RFC about the sort of numbers we expect in each subteam initially and (roughly, obvs) how quickly we expect the subteams to grow (for that matter the core team too, there are hints in this RFC that you would like the core team to grow, but aiui there has previously been pressure that it should not grow, or at least not quickly).

@nrc

nrc Apr 20, 2015

Member

"large number" is scary here - I hope the absorption of new people into decision making roles is slow and gradual. It might be worth being explicit in this RFC about the sort of numbers we expect in each subteam initially and (roughly, obvs) how quickly we expect the subteams to grow (for that matter the core team too, there are hints in this RFC that you would like the core team to grow, but aiui there has previously been pressure that it should not grow, or at least not quickly).

This comment has been minimized.

@Manishearth

Manishearth Apr 20, 2015

Member

+1. Ever since the initial draft I wasn't quite able to get a clear image of what a subteam should look like, though I didn't ask because it didn't occur to me consciously.

I've been assuming 5-10 per subteam, though it could be less. (timezones can be an issue with a small subteam though)

@Manishearth

Manishearth Apr 20, 2015

Member

+1. Ever since the initial draft I wasn't quite able to get a clear image of what a subteam should look like, though I didn't ask because it didn't occur to me consciously.

I've been assuming 5-10 per subteam, though it could be less. (timezones can be an issue with a small subteam though)

This comment has been minimized.

@aturon

aturon Apr 21, 2015

Member

It will likely vary by area, but yes, I think 5-10 is a good range. The moderation team probably wants to be a bit smaller.

And yes, of course this will be a gradual process.

@aturon

aturon Apr 21, 2015

Member

It will likely vary by area, but yes, I think 5-10 is a good range. The moderation team probably wants to be a bit smaller.

And yes, of course this will be a gradual process.

This comment has been minimized.

@nrc

nrc Apr 21, 2015

Member

I was thinking numbers-wise the modules should be like the core team: 4-6 is a good number, 8 is the point where we start to think about scaling again. Obvs, this is pretty much the same as 5-10, so this is agreement stated slightly differently :-)

@nrc

nrc Apr 21, 2015

Member

I was thinking numbers-wise the modules should be like the core team: 4-6 is a good number, 8 is the point where we start to think about scaling again. Obvs, this is pretty much the same as 5-10, so this is agreement stated slightly differently :-)

+(as part of the larger vision for Rust), which the leader is responsible for
+moving the subteam toward. Notably, this is how "module owner" is actually
+defined in Mozilla's module system:
+

This comment has been minimized.

@nrc

nrc Apr 20, 2015

Member

My particular preference for owner rather than leader is because I think that the leader should be first among equals, rather than a BDFL of an area. Just as we (nearly always) look towards the core-team as a whole for our current leadership, so it should with subteams.

@nrc

nrc Apr 20, 2015

Member

My particular preference for owner rather than leader is because I think that the leader should be first among equals, rather than a BDFL of an area. Just as we (nearly always) look towards the core-team as a whole for our current leadership, so it should with subteams.

+replaced by something like "peer" (following the module system tradition), or
+some other term that is less bland than "member". Ideally, the term would
+highlight the significant stature of team membership: being part of the
+decision-making group for a substantial area of the Rust project.

This comment has been minimized.

@nrc

nrc Apr 20, 2015

Member

In my ideal world 'peer' means being a peer for the project as a whole and the core-team are also peers with a particular responsibility towards strategic/global issues, rather than 'peer' being part of a sub-group.

@nrc

nrc Apr 20, 2015

Member

In my ideal world 'peer' means being a peer for the project as a whole and the core-team are also peers with a particular responsibility towards strategic/global issues, rather than 'peer' being part of a sub-group.

@nrc

This comment has been minimized.

Show comment
Hide comment
@nrc

nrc Apr 20, 2015

Member

Is there sill a role for the current weekly meeting or should its responsibilities be entirely covered by the subteams?

Can we have minutes for the core team meeting? And a general move towards more open communication between the core team? I would very much like to see some movement in that direction in this RFC.

Member

nrc commented Apr 20, 2015

Is there sill a role for the current weekly meeting or should its responsibilities be entirely covered by the subteams?

Can we have minutes for the core team meeting? And a general move towards more open communication between the core team? I would very much like to see some movement in that direction in this RFC.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Apr 21, 2015

Member

@nrc

Is there sill a role for the current weekly meeting or should its responsibilities be entirely covered by the subteams?

I think that if we make the move to subteams, the current meeting structure should be completely rethought. And yes, in particular the weekly meeting should be replaced by subteam meetings. I'm personally still interested in an additional, "town hall" style meeting, perhaps once per cycle.

Can we have minutes for the core team meeting? And a general move towards more open communication between the core team? I would very much like to see some movement in that direction in this RFC.

Sure, we can put out minutes of whatever meetings we wind up with (it's a little unclear how things will be structured if we move to subteams).

Member

aturon commented Apr 21, 2015

@nrc

Is there sill a role for the current weekly meeting or should its responsibilities be entirely covered by the subteams?

I think that if we make the move to subteams, the current meeting structure should be completely rethought. And yes, in particular the weekly meeting should be replaced by subteam meetings. I'm personally still interested in an additional, "town hall" style meeting, perhaps once per cycle.

Can we have minutes for the core team meeting? And a general move towards more open communication between the core team? I would very much like to see some movement in that direction in this RFC.

Sure, we can put out minutes of whatever meetings we wind up with (it's a little unclear how things will be structured if we move to subteams).

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Apr 21, 2015

Member

I think at the very least a summary of the discussions, and why each decision was made, would be nice.

Member

Manishearth commented Apr 21, 2015

I think at the very least a summary of the discussions, and why each decision was made, would be nice.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Apr 21, 2015

Member

@Manishearth

I think at the very least a summary of the discussions, and why each decision was made, would be nice.

I'm not sure what this is a reply to, but these summaries and explanations of rationales are already made when merging or closing RFCs -- it's something we've been working really hard to do with every RFC. They could certainly be consolidated into meeting minutes, but as I said above we try to avoid making decisions in meetings anyway. But maybe I'm misunderstanding what you mean?

Member

aturon commented Apr 21, 2015

@Manishearth

I think at the very least a summary of the discussions, and why each decision was made, would be nice.

I'm not sure what this is a reply to, but these summaries and explanations of rationales are already made when merging or closing RFCs -- it's something we've been working really hard to do with every RFC. They could certainly be consolidated into meeting minutes, but as I said above we try to avoid making decisions in meetings anyway. But maybe I'm misunderstanding what you mean?

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Apr 21, 2015

Member

Nah, it was a general comment on the entire minutes discussion. Never mind it :)

Member

Manishearth commented Apr 21, 2015

Nah, it was a general comment on the entire minutes discussion. Never mind it :)

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Apr 22, 2015

Member

After the discussion on this thread, the core team decided to start publishing minutes for its meetings, regardless of the outcome of this RFC.

The first set of minutes is up here. As you can see, rather than a transcript (which tends to have a mixed amount of detail, be difficult to follow, and require someone to focus on real-time transcription rather than the conversation), we've summarized the contents of the meeting post hoc.

Member

aturon commented Apr 22, 2015

After the discussion on this thread, the core team decided to start publishing minutes for its meetings, regardless of the outcome of this RFC.

The first set of minutes is up here. As you can see, rather than a transcript (which tends to have a mixed amount of detail, be difficult to follow, and require someone to focus on real-time transcription rather than the conversation), we've summarized the contents of the meeting post hoc.

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Apr 22, 2015

Member

\o/ nice 😄

Member

Manishearth commented Apr 22, 2015

\o/ nice 😄

@nrc

This comment has been minimized.

Show comment
Hide comment
@nrc

nrc Apr 23, 2015

Member

Awesome, happy to see the core team meeting minutes

Member

nrc commented Apr 23, 2015

Awesome, happy to see the core team meeting minutes

+ and future).
+
+* Ensures that simple, uncontentious changes can be made quickly, without undue
+ process burden.

This comment has been minimized.

@quantheory

quantheory Apr 25, 2015

Contributor

A minor nitpick: I would say "unnecessary" or "needless" rather than "undue". The phrase "undue process burden" sounds like a reference to the concept of "due process", which is well-known legal jargon in most English-speaking countries, but I think that's just a distracting coincidence.

@quantheory

quantheory Apr 25, 2015

Contributor

A minor nitpick: I would say "unnecessary" or "needless" rather than "undue". The phrase "undue process burden" sounds like a reference to the concept of "due process", which is well-known legal jargon in most English-speaking countries, but I think that's just a distracting coincidence.

@quantheory

This comment has been minimized.

Show comment
Hide comment
@quantheory

quantheory Apr 25, 2015

Contributor

I still need time to re-read/re-think this and the comments, but a few immediate thoughts:

  1. The CoC is a big deal. Like most other mature human beings, I prefer to avoid trolling and drama on the internet. In professional matters, I pay attention to explicit statements about non-discrimination, partly out of principle, and partly because, like most people, I'm in some of those marginalized categories. I prefer to know that the community has my back, so that I don't have to always watch my own. So even though it isn't the first (or second...) thing I look for in an open source project, just having a decent CoC made a good impression when I was first looking into Rust.

    (I also like the aside in the CoC that mentions that cursing is allowed, but not at others. I'm not going to promote obscene language for its own sake, however much I indulge in it myself. But it's important both to clarify what the priorities in the CoC are, and to deal with cultural differences in what's considered a curse word. In my experience, the distinction between "cursing about a situation" and "deliberately insulting other people" is almost never ambiguous to an attentive moderator, but people do try to defend themselves by blurring the line here.)

  2. I very strongly feel that there should be at least one subteam dealing with performance and portability (across hardware, not OSes). Non-x86 architectures and accelerators (most obviously GPUs) are a weakness for Rust right now. I sure as heck don't want to deal with such things, but I think that there are plenty of people with such interests. The community really needs a body of people who specialize in codegen (e.g. know intimately how LLVM actually works) and/or follow trends in hardware capabilities (to take a simple example, widening of registers for improved SIMD), and I really don't see such things fitting into the subteams for language design, the reference compiler, or libraries, even though these considerations do in fact impact all of the above.

  3. I think that the subteam hierarchy is, in general, inevitable. I have had this worrisome image in my head, which can be summarized as: How busy would it be if there was just one forum, where anyone who ever had a problem with C would know to raise an issue and actually expect to be heard by the standards committee? Of course, there are members of other language standards committees that you can contact without too much trouble, but older languages tend to be either more closed (so less expectation that anyone will listen to you as a user) or more populous (so there are more developers and committee members to field the many suggestions and requests) or usually both. I think that the best you can really do is to try for scaling that's O(log(n)) in the number of users by growing a deeper/broader hierarchy as the need arises.

  4. I don't actually think that over-enforcement of the CoC is likely to be an issue, unless some very excessive people are brought on as moderators. The most common problems I've seen for open-source projects are under-enforcement (especially when moderators are chosen due to their popularity in the community or popularity among the core team, which are traits that should actually disqualify individuals from being moderators) or simple corruption (someone invested in certain subprojects banning political opponents).

Contributor

quantheory commented Apr 25, 2015

I still need time to re-read/re-think this and the comments, but a few immediate thoughts:

  1. The CoC is a big deal. Like most other mature human beings, I prefer to avoid trolling and drama on the internet. In professional matters, I pay attention to explicit statements about non-discrimination, partly out of principle, and partly because, like most people, I'm in some of those marginalized categories. I prefer to know that the community has my back, so that I don't have to always watch my own. So even though it isn't the first (or second...) thing I look for in an open source project, just having a decent CoC made a good impression when I was first looking into Rust.

    (I also like the aside in the CoC that mentions that cursing is allowed, but not at others. I'm not going to promote obscene language for its own sake, however much I indulge in it myself. But it's important both to clarify what the priorities in the CoC are, and to deal with cultural differences in what's considered a curse word. In my experience, the distinction between "cursing about a situation" and "deliberately insulting other people" is almost never ambiguous to an attentive moderator, but people do try to defend themselves by blurring the line here.)

  2. I very strongly feel that there should be at least one subteam dealing with performance and portability (across hardware, not OSes). Non-x86 architectures and accelerators (most obviously GPUs) are a weakness for Rust right now. I sure as heck don't want to deal with such things, but I think that there are plenty of people with such interests. The community really needs a body of people who specialize in codegen (e.g. know intimately how LLVM actually works) and/or follow trends in hardware capabilities (to take a simple example, widening of registers for improved SIMD), and I really don't see such things fitting into the subteams for language design, the reference compiler, or libraries, even though these considerations do in fact impact all of the above.

  3. I think that the subteam hierarchy is, in general, inevitable. I have had this worrisome image in my head, which can be summarized as: How busy would it be if there was just one forum, where anyone who ever had a problem with C would know to raise an issue and actually expect to be heard by the standards committee? Of course, there are members of other language standards committees that you can contact without too much trouble, but older languages tend to be either more closed (so less expectation that anyone will listen to you as a user) or more populous (so there are more developers and committee members to field the many suggestions and requests) or usually both. I think that the best you can really do is to try for scaling that's O(log(n)) in the number of users by growing a deeper/broader hierarchy as the need arises.

  4. I don't actually think that over-enforcement of the CoC is likely to be an issue, unless some very excessive people are brought on as moderators. The most common problems I've seen for open-source projects are under-enforcement (especially when moderators are chosen due to their popularity in the community or popularity among the core team, which are traits that should actually disqualify individuals from being moderators) or simple corruption (someone invested in certain subprojects banning political opponents).

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Apr 25, 2015

Member

I very strongly feel that there should be at least one subteam dealing with performance and portability (across hardware, not OSes).

I don't think we'll need a decision-making subteam here -- any decisions can be handled by the core or the compiler subteam, and there are people who do occasionally make PRs about this.

Member

Manishearth commented Apr 25, 2015

I very strongly feel that there should be at least one subteam dealing with performance and portability (across hardware, not OSes).

I don't think we'll need a decision-making subteam here -- any decisions can be handled by the core or the compiler subteam, and there are people who do occasionally make PRs about this.

@quantheory

This comment has been minimized.

Show comment
Hide comment
@quantheory

quantheory Apr 25, 2015

Contributor

@Manishearth I simply disagree. I regard this as a separate and essential specialty. The core team is by design not intended to deal with specialties, and my understanding is that the reference compiler team will have a lot of competing concerns. (Besides which, language design and libraries are both as relevant as the compiler.)

To be frank, I suspect that we will get by without such a subteam for a while, because it's not completely critical, and because we may not have enough people who are invested in Rust and prefer to specialize in hardware yet. (We have occasional RFCs, but fewer than I would expect for a systems language.) I think that in the medium/long run maintaining competitive performance will be difficult, though, without a body of specialists who look specifically at throughput and the ability to express various optimizations in Rust.

Contributor

quantheory commented Apr 25, 2015

@Manishearth I simply disagree. I regard this as a separate and essential specialty. The core team is by design not intended to deal with specialties, and my understanding is that the reference compiler team will have a lot of competing concerns. (Besides which, language design and libraries are both as relevant as the compiler.)

To be frank, I suspect that we will get by without such a subteam for a while, because it's not completely critical, and because we may not have enough people who are invested in Rust and prefer to specialize in hardware yet. (We have occasional RFCs, but fewer than I would expect for a systems language.) I think that in the medium/long run maintaining competitive performance will be difficult, though, without a body of specialists who look specifically at throughput and the ability to express various optimizations in Rust.

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Apr 25, 2015

Member

The thing is, the subteams are not for working on an issue, they are for prioritization and decision making. There's not much decision making to be done here, mostly just work. There may be occasional prioritization necessary and this sort of stuff can be handled by the core team (similar to all the other fields which rarely need a decision).

A group of specialists can be formed; I just don't see how it fits into the subteam system.

Member

Manishearth commented Apr 25, 2015

The thing is, the subteams are not for working on an issue, they are for prioritization and decision making. There's not much decision making to be done here, mostly just work. There may be occasional prioritization necessary and this sort of stuff can be handled by the core team (similar to all the other fields which rarely need a decision).

A group of specialists can be formed; I just don't see how it fits into the subteam system.

@quantheory

This comment has been minimized.

Show comment
Hide comment
@quantheory

quantheory Apr 25, 2015

Contributor

@Manishearth OK, I agree now.

Contributor

quantheory commented Apr 25, 2015

@Manishearth OK, I agree now.

@bill-myers

This comment has been minimized.

Show comment
Hide comment
@bill-myers

bill-myers Apr 26, 2015

Have you considered having a single person in charge, possibly elected by the core team?

The issue with having a team in charge is that decisions may happen (or not happen) without any single person feeling truly responsible for them, which may result in bad decisions or inaction where action would be necessary.

As an example, you could have a situation where something is criticized and everyone on the core team could legitimately respond with "well, I'm not totally sure about that, but we decided to do it this way last meeting" and do nothing, while a single leader would have to either back up his decision or realize he made a mistake and move to correct it.

Have you considered having a single person in charge, possibly elected by the core team?

The issue with having a team in charge is that decisions may happen (or not happen) without any single person feeling truly responsible for them, which may result in bad decisions or inaction where action would be necessary.

As an example, you could have a situation where something is criticized and everyone on the core team could legitimately respond with "well, I'm not totally sure about that, but we decided to do it this way last meeting" and do nothing, while a single leader would have to either back up his decision or realize he made a mistake and move to correct it.

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Apr 27, 2015

Member

For subteams or the core team? Subteams have a leader, except for the mod subteam.

The core team has a bettry interpersonal dynamic than that I think -- If such things are happening there's a problem with the team.

Also fwiw most decisions will be made by the relevant subteam, which will be headed by a core team member (?), so for an individual decision there is a "responsible" party. ish.

Member

Manishearth commented Apr 27, 2015

For subteams or the core team? Subteams have a leader, except for the mod subteam.

The core team has a bettry interpersonal dynamic than that I think -- If such things are happening there's a problem with the team.

Also fwiw most decisions will be made by the relevant subteam, which will be headed by a core team member (?), so for an individual decision there is a "responsible" party. ish.

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Apr 29, 2015

Member

Seems like we've reached a fixed point on this?

I guess we should move to the "final comment period" for this RfC then 😛

Member

Manishearth commented Apr 29, 2015

Seems like we've reached a fixed point on this?

I guess we should move to the "final comment period" for this RfC then 😛

@ubsan

This comment has been minimized.

Show comment
Hide comment
@ubsan

ubsan Apr 30, 2015

Contributor

Final comment: 👍

This is a real step forward, and I'm glad we're taking it.

Contributor

ubsan commented Apr 30, 2015

Final comment: 👍

This is a real step forward, and I'm glad we're taking it.

@aturon aturon referenced this pull request in rust-lang/rust May 4, 2015

Merged

std: Remove index notation on slice iterators #25006

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth May 6, 2015

Member

Time to merge? :D

Member

Manishearth commented May 6, 2015

Time to merge? :D

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton May 7, 2015

Member

After giving this RFC a go through a trial run of the "final comment period", it looks like it's come out quite well! At this point there appears to be broad consensus that this is a great step forward for Rust's governance, both improving its transparency, scalability, and openness. As such, I'm now going to merge this RFC. Thanks again for everyone's discussion on this topic, it has been quite valuable!

The core team has been discussing the initial set of subteams and membership, and more details are soon to follow. This will also include an initial sketch for how the subteams may operate with guidelines about communication, status reports, etc. Stay tuned!

Member

alexcrichton commented May 7, 2015

After giving this RFC a go through a trial run of the "final comment period", it looks like it's come out quite well! At this point there appears to be broad consensus that this is a great step forward for Rust's governance, both improving its transparency, scalability, and openness. As such, I'm now going to merge this RFC. Thanks again for everyone's discussion on this topic, it has been quite valuable!

The core team has been discussing the initial set of subteams and membership, and more details are soon to follow. This will also include an initial sketch for how the subteams may operate with guidelines about communication, status reports, etc. Stay tuned!

@alexcrichton alexcrichton merged commit c3f9fda into rust-lang:master May 7, 2015

@steveklabnik steveklabnik referenced this pull request in github/opensource.guide Aug 19, 2016

Closed

[RFC] Sustaining Growth > Leadership & Governance #38

@chriskrycho chriskrycho referenced this pull request in rust-lang/rust Dec 30, 2016

Closed

Document all features in the reference #38643

0 of 17 tasks complete

@chriskrycho chriskrycho referenced this pull request in rust-lang-nursery/reference Mar 11, 2017

Closed

Document all features #9

18 of 48 tasks complete

@carols10cents carols10cents referenced this pull request in request-for-explanation/podcast Jul 6, 2017

Open

Scaling Rust's Governance #1068 #23

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment