You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This discussion kicked off in the SIG community meeting around how to make it possible for our community 1) to have a better idea of what the SIG is focused at a macro level 2) to have a clear understanding of longer-term, higher level directional interests some of which may span multiple releases. There is a 3) item which is somewhat related: show what the sig wants to get into a release.
Other examples include:
Areas that the SIG is focused on (and not focused on).
Architectural directions
Areas of tech debt
General improvement ideas that could be pursued.
It is the case today that for new contributors discovering these things is an informal process via queries on Slack, discussions in live meetings.
It would be a huge benefit to the community and to the leads:
New proposals would be better aligned to the overall project direction
We can highlight important tech debt items, code base improvements that are highly desired but not obvious simply looking at the code base.
Give generally good visibility to what a SIG is working towards.
I acknowledge that maintaining this form of documentation does take effort, both to generate and maintain. To make the level of effort low, I don't think there is any real requirement on the format of the documentation other than 1) it exists 2) it's easily discoverable (e.g. from the sig homepage).
I see that the SIG-POLICY group does maintain a project board and this could be a good low cost way to maintain this kind of information. Could we use this a model that we can recommend to other sigs to see how it works?
It's the case that maintaining the freshness of the board itself does not necessarily need to fall to the leads -- anyone with interest from the community could help out -- and it would be a low barrier to entry to contributing to the project.
I like the idea of doing something here that we could start small and build up as the involvement in any given area grows. Here's a few thoughts on what could work:
When we create a SIG, we can create a project similar to the SIG-Policy one.
SIGs would be encouraged to periodically have a discussion about which areas are being actively worked on. This is a useful discussion topic for the SIG anyway, and the result of that discussion could be added into the project.
This discussion should happen every few months.
This discussion may happen more frequently if it's valuable to do so.
If someone is working on something, or if there is a need for some change to be made, add an item to the project.
Minimal suggestion would be to just add a draft item if it's just a rough idea (screenshot below).
If there's at least a couple of people interested in working on that item, create an issue with a description of what the proposal is and why it makes sense.
Optionally, SIGs could assign a milestone to specific items to indicate that the item is being actively worked on and the item is planned to target a particular development cycle.
I think this make sense as a good start -- Github projects look to be a pretty lightweight way to organize what probably already exists as lists of issues/discussions/PRs with particular labels and will be quite discoverable as more SIGs use it as a mechanism.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
This discussion kicked off in the SIG community meeting around how to make it possible for our community 1) to have a better idea of what the SIG is focused at a macro level 2) to have a clear understanding of longer-term, higher level directional interests some of which may span multiple releases. There is a 3) item which is somewhat related: show what the sig wants to get into a release.
Other examples include:
It is the case today that for new contributors discovering these things is an informal process via queries on Slack, discussions in live meetings.
It would be a huge benefit to the community and to the leads:
I acknowledge that maintaining this form of documentation does take effort, both to generate and maintain. To make the level of effort low, I don't think there is any real requirement on the format of the documentation other than 1) it exists 2) it's easily discoverable (e.g. from the sig homepage).
I see that the SIG-POLICY group does maintain a project board and this could be a good low cost way to maintain this kind of information. Could we use this a model that we can recommend to other sigs to see how it works?
It's the case that maintaining the freshness of the board itself does not necessarily need to fall to the leads -- anyone with interest from the community could help out -- and it would be a low barrier to entry to contributing to the project.
All reactions