Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Project Groups #2856

Open
wants to merge 1 commit into
base: master
from
Open

Conversation

@XAMPPRocky
Copy link

XAMPPRocky commented Jan 22, 2020

Rendered

Formalises the different groups in the rust lang organisation (specifically working groups and project groups).

Thank you to @nikomatsakis, @valgrimm, and everyone on @rust-lang/wg-governance who helped review this RFC.

Copy link
Member

spacekookie left a comment

I left some comments in the RFC, might finish the review later.

I'm quite excited about the idea of having a more official way to create groups and teams, although I think the distinction between a team (like lang or lib) and a working group (like embedded, or CLI) seems a bit arbitrary, i.e. would we want to create new teams or just working groups?

text/0000-project-groups.md Show resolved Hide resolved
independent of The Rust Programming Language's Working Groups. It's great that
we have a community able to self organise in this way, however it has led to
some confusion over who is supporting these efforts, and whether they're
considered _"official"_ Working Groups.

This comment has been minimized.

Copy link
@spacekookie

spacekookie Jan 22, 2020

Member

Is this actually a problem? I think it ultimately it boils down to people wanting to know if their efforts will make a difference, or if a group has the power to make decisions. Every group can make decisions in it's own problem domain, but when it comes to overall project choices there's a lot of social dynamics involved that go beyond the question if a working group is official or not. I think focussing on that would be more important

This comment has been minimized.

Copy link
@XAMPPRocky

XAMPPRocky Jan 22, 2020

Author

The consideration of whether a working group is official is more about access and organisational policy rather than about whether a person's choices are to be considered authoritative. There's a lot of places where we have to draw a line somewhere. One example of this is all hands attendance. Official working group leads get invited, unofficial ones do not.

text/0000-project-groups.md Show resolved Hide resolved
text/0000-project-groups.md Show resolved Hide resolved
Copy link
Member

Manishearth left a comment

I've already read through this in the past and followed discussions (though I didn't have time to participate, sorry), but I'm +1 on this.

At some point it would be interesting if we could have something similar to the W3C where community groups are semi-formalized and provided support but still mostly unofficial.

text/0000-project-groups.md Show resolved Hide resolved
@XAMPPRocky XAMPPRocky force-pushed the XAMPPRocky:project-groups branch from 75b1ea6 to 899b19d Jan 28, 2020
@XAMPPRocky

This comment has been minimized.

Copy link
Author

XAMPPRocky commented Jan 28, 2020

@Manishearth W3C was one of the organisations I looked at when writing this.

One thing I want to address in this RFC, that it doesn't currently. Is that it is a common pain point that our membership is often fickle, and it can be unclear who is in a group, and who isn't. People often leave members in teams even when they don't participate as they don't want to create friction with the person who is inactive. I think it would beneficial to have some kind of light policy to allow removal of inactive members.

If we look at the Python Software Foundation, they have a requirement for someone to be considered a contributor they dedicate five hours towards projects that advance their mission, and for someone to be considered a Shepherd (Managing Member), they dedicate 5 hours a month towards managing their working group.

If we had this I don't think we would need to rigorously enforce such a time requirement. More that it should be a guideline for people to ask themselves when evaluating whether they are able to commit to being member or shepherd, and whether a member or shepherd is still active and can be safely removed. Of course a team member being removed for inactivity doesn't mean that the person can't later rejoin once they are more active again.

matches the intent behind each of these three separate groups, as well as codify
the processes that these groups have been using to help facilitate creating
new groups.

This comment has been minimized.

Copy link
@valgrimm

valgrimm Jan 28, 2020

Proposed edit:
This RFC aims to provide clarity by:
*Providing distinct terminology matching the purpose of each group (there are three)
*Codifying processes used to facilitate the creation of new groups
*Promoting clarity about whether groups and the contributors associated with those groups are active
*Establishing a process for collecting insights and archiving resources when a group's work is done

This comment has been minimized.

Copy link
@valgrimm

valgrimm Jan 28, 2020

Hm, and also *Encouraging reflection about the time committment associated with being a shepherd


<p align="center">
<img src="../resources/project-group-workflow.png"
alt="A flow diagram showing each step of a project group"

This comment has been minimized.

Copy link
@valgrimm

valgrimm Jan 28, 2020

I propose:
"Each step in the project group lifecycle"

- **Community Group** would act as a catch all term for community self
organising groups that are independent of the Rust Programming
Language Organisation.

This comment has been minimized.

Copy link
@valgrimm

valgrimm Jan 28, 2020

Is it useful to add clarity in the descriptions above about where liaisons are present and where shepherds are needed?

organising groups that are independent of the Rust Programming
Language Organisation.

## Life-cycle of a Project Group

This comment has been minimized.

Copy link
@valgrimm

valgrimm Jan 28, 2020

Before this section I would add something like this, based on the latest comment on this RFC (please edit as necessary)

A word on shepherd and member time commitments

It is valuable for all Rust contributors to be aware of the time committment involved in joining a project as a member or a shepherd.

It isn't useful to rigorously enforce a time requirement that determines whether a contributor is an active project member.

However, the Python Software Foundation (PSF) provides a useful set of benchmarks for assessing the time committment involved. To be considered a contributor to the PSF, that person should dedicate five hours towards projects that advance the PSF mission, and for someone to be considered a Shepherd (Managing Member), they should dedicate five hours a month towards managing their group.

If a project group or working group member finds that they do not have time to work with their team, they can choose to have their name removed from the project during their inactive period and rejoin once they are able to be more active again.

Project and working groups should also be able to discuss the status of potentially inactive members by contacting the relevant individuals directly

--
I'm writing this a very tired because the email thread drew me in, feel free to tweak. Also, after "directly" above, I feel like something more is needed there, but it is a touchy topic so I'm not sure where and how to safely tread

Hope this helps.

@Manishearth

This comment has been minimized.

Copy link
Member

Manishearth commented Jan 29, 2020

It's tricky: In a volunteer organization, sometimes people just need to disappear for a while (I had to temporarily cut down a lot of my involvement in the rust project near the end of last year due to travel and work, I've had team members in similar situations, etc), and even if the idea is for the process to be low-friction and reversible, the end result is often that members feel obliged to do some halfhearted participation. Sure, that's not the intent for such a process, but it can end up being the effect.

This is not to say that we shouldn't do such a thing: I like the idea of having a rough guideline time period, and allow teams to have a process to deal with this if they so choose. This won't be a problem in the case of teams who are aware a member is busy, or teams which are really small (and often low-volume), where it is not desirable to ask people to leave just because they aren't constantly contributing. This seems to be roughly what is proposed; to be clear I'm not disagreeing, I just want to draw a good boundary.

@XAMPPRocky

This comment has been minimized.

Copy link
Author

XAMPPRocky commented Jan 29, 2020

@Manishearth Yeah I agree with everything you just said. I don't think the issue we run into is participants disappearing. I think the problem we more often run into, is when the people who disappear are leads or shepherds. When they disappear, people are often being blocked on that person re-appearing because the task/project is meant to be their responsibility, and they have no process for continuing the work.

even if the idea is for the process to be low-friction and reversible, the end result is often that members feel obliged to do some halfhearted participation. Sure, that's not the intent for such a process, but it can end up being the effect.

Yes, that would be probably the worst outcome of setting this process. The process shouldn't be aimed at having only people that are constantly contributing, rather it should be built around the fact that people will come and go, and how we handle when they are gone.

@valgrimm

This comment has been minimized.

Copy link

valgrimm commented Jan 29, 2020

Do the comments I made with suggestions help with this?


- Neither group has _"formal decision making power"_: meaning that they are not
able to accept RFCs on `rust-lang/rfcs`. Similarly, neither group has
representation on the Core team.

This comment has been minimized.

Copy link
@programmerjake

programmerjake Jan 30, 2020

One thing that should probably be explicitly mentioned: core team members are not excluded from joining groups.

@XAMPPRocky

This comment has been minimized.

Copy link
Author

XAMPPRocky commented Jan 30, 2020

@valgrimm What you wrote would work well, I'm just mainly not sure about the requirement itself, and need to think about it more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

7 participants
You can’t perform that action at this time.