Okay here is a mockup of a really rough draft for using issues: (I got too caught up in trying to make things perfect so I’m just putting up something rather than try to fully understand all the aspects which collectively the team understands far better than me - on that note, all input is welcome). Side note, I thought it was logical (for me personally as well as for newcomers) to make an issue guide before we make an issue grooming guide is made. Relying on referencing gitlab for the basic stuff:
I would make a point of removing/striking through some of these options that we don’t use but given we are in discussion for implementing usage of various things, I’ll table the details for which of these parts are really in our usage of gitlab issues.
Generally, a good issue should be:
not be redundant/duplicate of another issue (search to double check!)
Clearly defined (ideally, concisely and with a driver statement if necessary)
Appropriately labeled
Assigned (or unassigned) appropriately
Filled with actionable next steps
Reference relevant blockers or related milestones, issues and merge requests
Again this is very rough but I wanted to get something up as it’s something I’ve been thinking / reading a lot about and trying to wrap my head around all the aspects and possibilities (of which there are too many to track to and fully grasp in a short time frame, so I was hoping for collective input to get help in assessing where any gaps might have been). Thanks ya’ll
We want a portion of this to instead be at the forum. I’m not sure where the line should go. Incidentally, GitLab itself also uses Discourse (see https://forum.gitlab.com), so they have some similar situation. Discourse is just superior at handling discussion overall. But the closer something is to a specific task, the more it seems sensible to do in issues at GitLab.
As I encountered in writing Driver statements for mission and for meetings - #3 by wolftune, we should clarify the relation of different parts of the Sociocracy process versus issues. After a driver statement comes proposals, and jumping from driver to defined task risks skipping that stage (which is okay if we’re consciously knowing that it’s fine in a specific case).
We could potentially use issues to draft driver statements. But one idea could be that we generally draft driver statements on the forum, and we also make proposals on the forum. We could then open issues once we have a doable proposal (which might need refining, but the basic concept is agreed as a task to do).
WDYT about driver statements in all issues? The priority of an issue would be clear immediately and could be reviewed by others more easily. When circumstances relevant for low/high priority change, this would be obvious by reading the driver statement.
I think this information belongs into the issues, as opposed to e.g. forum posts that then link to the issues. When you see an issue, you need to know whether it has priority or not – the more obvious the prioritization becomes, the more people will unconsciously do the important things.
I think there may be cases where driver statements are unnecessary overhead. But we could start with the idea of driver in every issue and see how it goes.
If we have a driver that then gets a proposal with distinct enough tasks for multiple small issues, each could quote the driver.