Hi Eli, On Sun, 2020-02-23 at 17:50 +0200, Eli Zaretskii wrote: > When we get appointed, we receive > a 1000-word message from RMS with some quite non-trivial instructions, > including, but not limited to, a pointer to maintain.texi as the place > to find specific policies and guidelines that are mandatory to follow. > That is what I alluded to when I said "maintaining a GNU project > according to the guidelines". I don't know how things are on your > plate, but for me following those guidelines takes most of my free > time, and requires some non-trivial efforts.
I am glad you bring this up. There are indeed some guidelines that get communicated to some maintainers. Although it is unclear if everybody gets the same message. I cannot remember I did, but it has been 20 years ago now. Most of these things get passed over from maintainer to maintainer. And there were some recent changes that made me scratch my head why they were suddenly added without any discussion. But those mostly describe the what, not the why. The GNU Social Contract describes the core goals, the why we do GNU. They can be seen as a summary of the GNU mission. The policies and recommendations you mention are the how. And there are indeed a lot of texts mixing core policy, technical suggestions for doing things the GNU way. One practical problem with that is of course interpreting what the GNU way really is. That is not because we haven't documented that, but ironically because we have documented so much :) And each GNU maintainer is supposed to interpret and decide whether or not all those recommendations are applicable to their package and/or use them to write more specialized policy for their project. 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. Now that we have a GNU Social Contract, that describes the core mission of GNU, we can more easily reason about all these policies and recommendations and how some of them might indeed be mandatory and which are just suggestions that might or might not apply in the technical context of your package and developer community. Cheers, Mark