MESSAGE
| DATE | 2020-02-27 |
| FROM | Mark Wielaard
|
| SUBJECT | Re: [Hangout - NYLXS] The General Public Licence (GPL) as the basic
|
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
_______________________________________________
Hangout mailing list
Hangout-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/hangout
|
|
