Hi, On Mon, 2019-10-21 at 17:16 +0200, Félicien Pillot wrote: > On Mon, 21 Oct 2019 17:08:33 +0200 > Mark Wielaard <m...@klomp.org> wrote: > > In practice GNU already is mostly a bottom-up organization, where > > the GNU hackers that do the actual work shape the project, but it > > would be nice to make it more formally so. > > What do you suggest?
First I am probably using the wrong terminology. Second bootstrapping something like this is probably much trickier than I anticipate. Especially given the current GNU governance structure or non-existence of it, depending on who you ask. But let me try to explain how GNU would ideally look like to me. Then we can discuss how practical those suggestions would be. I would like to see GNU organized in such a way that GNU volunteers, who devote so much time and energy to GNU, will be able to grow and become the next generation of GNU leaders through some kind of apprenticeship. People should always be on the outlook of who could replace them by mentoring and promoting others who show they contribute positively the GNU way. Various GNU project actually already work a bit like this. First you become a contributor by submitting some trivial patches, then you add more meaningful patches and a copyright assignment/disclaimer, when consistently providing meaningful patches and showing you can cooperate with other developers following the GNU way you get committer status and can mentor others by reviewing and installing their patches, you might become a subsystem maintainer or even a GNU (co-)maintainer and be trusted to and responsible for writing policy for the project. The GNU maintainers of related packages can then come together to form a technical committee to coordinate GNU policy to make the GNU system more consistent that others might then adopt for their packages. One practical problem with that is of course interpreting what the GNU way is. We all probably have a feeling of what is and isn't the GNU way, but it is actually hard to describe the core. That is not because we haven't documented that, but ironically because we have documented so much :) Just look at the documents that a GNU maintainer is supposed to interpret and decide whether or not they are applicable to their project and/or use to write more specialized policy for their project: Information For Maintainers of GNU Software: https://www.gnu.org/prep/maintain/ GNU Coding Standards: https://www.gnu.org/prep/standards/ For the basic ideas of GNU and Free Software: https://www.gnu.org/gnu/the-gnu-project.html https://www.gnu.org/philosophy/free-sw.html https://www.gnu.org/philosophy/categories.html https://www.gnu.org/philosophy/compromise.html https://www.gnu.org/philosophy/words-to-avoid.html https://www.gnu.org/gnu/linux-and-gnu.html https://www.gnu.org/gnu/gnu-linux-faq.html https://www.gnu.org/philosophy/open-source-misses-the-point.html There are a lot of shoulds, but very little musts in those documents. Which is good, because the amount of information is really a lot. And it gives GNU maintainers a lot of freedom to implement the suggested policies and decide what does or doesn't apply in the specific (technical) context of a package. But it takes a lot of time to describe the responsibilities, delegation and decision frameworks for a package to bring in more people who can share the maintainer load. It would be good to try to distill a small core of musts, a summary of sorts, that can be more easily communicated as a kind of social contract for GNU. e.g. the free-sw definition as defined by the FSF might be seen as our core. But some of the things in words-to-avoid are just nice to haves, of sometimes playful ways of speech. While some things in the standards like the requirements around usage of trademarks is again essential, but now for legal reasons (and then there is the imho odd reference to not using "win" in that same section, which seems more like a nice to have again). Basically I believe we have too much information. And it would be good to be more clear on which information is what and how essential it is to the GNU way. Another practical problem with this is that I can see how this works when we narrowly define GNU as a collection of packages that form the GNU operating system. But there are other GNU volunteers than just developers. There are people who maintain websites, translators and those that keep various infrastructure running, like savannah or package specific servers and those that organize meetings and conferences like the GNU Tools Cauldron or the GNU Hacker Meetings. And then there are things like the GNU Education Team or packages/projects which are kind of extensions of the core GNU operating system. I haven't really thought how to precisely fit everybody in the bottom-up hierarchy, which admittedly is very developer/package oriented. Cheers, Mark _______________________________________________ gnu-misc-discuss mailing list gnu-misc-discuss@gnu.org https://lists.gnu.org/mailman/listinfo/gnu-misc-discuss