-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Add a process for working groups #13162
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds like a solid proposal, I especially like the part of SMEs/maintainers staying patient and supportive until the design doc is made. Getting large backlash immediately from someone with some level of authority would be hugely demotivating, especially considering the rust community has a habit of rejecting every new feature due to perceived costs (compile time, runtime performance, complexity, maintainance workload, etc).
This adds much-needed clarity and organization to a process that has been happening informally for ages. I think the way it's drawn up here is great. We also might want to make up a design-doc template at some point. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this. Similar informal working groups have been very effective in the past, and I think formalizing them will help significantly in coordinating work as well as making everything more discoverable and easier to track. I mostly have just a few language nits
Co-authored-by: Joona Aalto <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it! Just one thought / suggestion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is my favorite organizational idea do far.
@cart I've added a section for the initial check as you requested. I think it's a reasonable idea, as long as we can keep the process light and turnaround fast. When you're happy with this, feel free to merge. |
Awesome thanks! I'm happy with it. Lets give it a day or so to receive a few more eyes and then I'll merge if nothing else comes up. |
I'm quite happy with this, and I think that if it gains traction it could be a huge boon for the ecosystem. I especially like that the document focuses on this as a means of onboarding new contributors, which I regard as quite important. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it! I think this can definitely help with a huge problem: is the thing I want to implement even going to be accepted? Getting the consensus approval right at the start should hopefully keep motivation high and encourage others to contribute to the initiative.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a fantastic process change that will address some of my current pain points with contribution and upstreaming. Thank you!
I think this would work really well even for things with a single code contributor if they are large enough - having a cohesive place for something like the #11426 PR would likely have helped keep track of things more easily. |
Thank you to everyone involved with the authoring or reviewing of this PR! This work is relatively important and needs release notes! Head over to bevyengine/bevy-website#1309 if you'd like to help out. |
Objective
Coordinating work can be hard, and figuring out how to get started with contributions is always a challenge.
We've had great success with informal working groups in the past (primitives, bevy_color, stageless). However, they're not at all discoverable, are hard to keep track of and tend to flood the dev channels that they're in.
When their messages are moved to Discord threads, they then get completely scattered and buried.
Solution
We can formalize the working groups in a very process-light way, and give them a discoverable home by using a curated forum channel on Discord.
While we'll still need more stringent PR reviews for particularly complex or architectural changes made as part of these initiatives, a broad sign off on the course of action goes a long way to building consensus. By baking that into the process, I think we can avoid a lot of wasted work and relitigation without encouraging mega-PRs or RFCs.