Hi Mark, > Right. It is certainly a messy process, which doesn't always help > people trust that everybody is participating in good faith. Some > structure would certainly help. So if the goal is to collectively > decide about the organization of the GNU project and create a project > that everyone can trust to defend their freedom, then here are the > steps I believe we have to do (not necessarily in this order, and some > might be done in parallel): > > - Document how different people believe things actually work now. > This is what we have been doing on this list for the some time. > It isn't easy because people honestly have completely different > views on how things are working currently. Partly because of the > dual role of the FSF President and the Chief GNUisance. > And things have obviously changed over the last 30 years, but > haven't really been documented properly and different subgroups > have gone their own way. GNU hackers who have an fencepost account > honestly have a completely different view of the organization > and processes than those who don't use fencepost. Similar to how > GNU projects around savannah have a completely different view of > the organization of GNU from those who use sourceware. And again for > those who use www.gnu.org and/or lists.gnu.org and those who use > their own hosting for communicating with users and other hackers. > > This is really, really, really hard because so much simply isn't > documented or discoverable unless you are intimately familiar > with one of the subgroups. And it is really easy to dismiss someone > saying how things work as just their opinion to advance their agenda > because you aren't familiar with another subgroup who has followed > their own processes over the last couple of decades. And it is really > easy to describe ones own experiences as the one and only truth. > Things easily get a bit heated. But lets try and be kind to each > other. > > - Describe what the core values are that we all share. Something we > all agree on that can form the basis for shared goals and > understanding. This is the draft of the GNU Mission or GNU Social > Contract we have been working on. Ideally this applies to any > governance structure we might come up with or even the current > one if we can agree on that. > > - Define the members (stakeholders) of the GNU project. Identify the > people actually doing the work pushing the mission forward and > who also endorse those core values. As a start this can be the > GNU maintainers, who can then identify others to who they delegate. > Acceptance of the GNU Social Contract can help with this. > > - Identify the different roles those members have and what kind of > team they are part of. Which rights and responsibilities are > needed to most effectively do the work for each role. What makes > them empowered to do their work properly. What is working and what > isn't working in the current structure. And what structure will > work for all members to trust each other to collectively work > on the mission. > > - Discuss with the FSF how we make any governance changes needed a > (legal) reality. The various discussion documents and proposals > we have been sending to the FSF are part of this.
I think this is essentially a reasonable and logical roadmap. Thank you for taking the time to write it down. I'd like make note that in point 4 you state "As a start this can be GNU maintainers". This preempts the first point of figuring out the "who" and "how" and renders it pointless as well as invites people to reason backwards from your personally preferred outcome. This also applies to "Ideally this applies to any governance structure we might come up with or even the current one if we can agree on that." by presenting structural changes to governance as a fait accompli, even though that doesn't fairly represent the current situation. I think Andreas Enge summarised the main points in a more neutral fashion: > - Document how different people believe things actually work now. > - Describe what the core values are that we all share. > - Define the members (stakeholders) of the GNU project. > - Identify the different roles those members have and what kind of > team they are part of. Which rights and responsibilities are > needed to most effectively do the work for each role. What makes > them empowered to do their work properly. I think it would be a good idea to stick to this roadmap instead of pushing forward initiatives that try to push the whole discussion in a more partisan direction. cheers, Andreas R.