On Tue, Dec 31, 2019 at 12:49:03PM +0100, Mark Wielaard wrote: > The latest version of the GNU Social Contract can be found here: > https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-11/msg00358.html > There were some minor wording suggestions since on the list.
Thanks. I think that was the version I used, but I got the date wrong. > > In response to that request, earlier on-list feedback, and expressed > > support for having a couple of > > succinct documents that describe the structure and mission of the GNU > > project, I composed a version > > based on Andreas Elke's draft that attempts to address some of the > > problems that were raised. > > Thanks. But I think your version mixes why, what and how a little. Can you elaborate on that? I have an inkling about what you could mean by the "why", "what", and "how", but I wouldn't want to spend time answering the wrong questions. > The social contract says what users and the free software community can > expect from the GNU project, but doesn't prescribe how GNU volunteers > working on it do it, or how the project is structured precisely. That could be considered a shortcoming. Andreas Enge, in response to the difference between a "Social contract" and a "Code of Conduct" writes on the 6th of November: "a social contract, which is a "mission statement" and statement of the general principles of an organisation, as well with respect to the inner workings as well as an engagement to the outer world" which could be summed up as: - a statement of the general principles of an organisation, - a statement with respect to the inner workings - a statement regarding an engagement to the outer world Has this layout changed? > It > looks like your document and the social contract could be separate > documents because they don't really conflict. That might make it more > clear what you are precisely proposing. There have been various statements in support of a general document that would "describe the structure and mission of the GNU project", even allegedly by rms himself Since no such document exists, it would need to be agreed on by everyone who could be loosely defined as "part of the GNU project" to serve as any sort of guideline. The "GNU social contract" as it is, is not agreed on by everyone. The "GNU - Principles and Guidelines" attempts to address that. It's an adjusted version of the social contract that hopefully at some point can be agreed on by everyone, and serve as a first solid step towards finding a new governance model for the GNU project. > > This amended version: > > > > - is closer to the situation as it currently exists and as such > > should need no additional agreement > > or undersigning of existing maintainers since it should describe the > > status quo. > > Maybe you could state what in the GNU Social Contract doesn't describe > the status quo? A fairly significant change would be that maintainers would be required to sign an extra document. This has been mentioned repeatedly  by the writer of the first version of the social contract, Ludovic Courtès. Has this idea been dropped? If it has not been dropped, questions about enforcement have been fielded by Federico Leva  but not been readily addressed. Another point where the social contract deviates from the status quo is the complete absence of the FSF or existing governance. The social contract, as it is, simply gives "the GNU project" project-wide governance without precisely defining "the GNU project". Before entities are bestowed with formal agency, their makeup should to be precisely defined, otherwise you might end up with a cabal, alleged or otherwise. > I don't see it as a problem that GNU > maintainers outside their GNU work might not fully adhere to the social > contract as long as we can trust each other to do when we are working > together on the GNU project itself. My apologies. I meant GNU maintainers adherence to software freedom in the course of their GNU work. As things are, GNU maintaners can use non-free operating systems, even in publicly giving presentations about their GNU work. They can also, for example, be drawn to GNU maintenance for the technical challenge it provides instead of promoting the wider ideas that are usually associated with the GNU project. Given that they abide by the license of their GNU software, there is no conflict here, but the fact remains that being a GNU maintainer doesn't automatically gives one the right perspective to safeguard software freedoms. Of course, maintainers could be asked to sign a document that promises they will live up to the GNU project's standards, but what is to be done with existing GNU maintainers who are working on GNU for reasons other than software freedom? Will they be excluded from GNU project decision making? And maybe more importantly: will the GNU project reject aspiring maintainers who will not sign a document that puts the responsibility of maintaining the larger ideas of software freedom on their person? > > - guarantees GNU maintainers can continue to work on the project as a > > loosely associated group of hackers > > if they so desire even though a more regimented approach can be > > implemented within each seperate component > > or package. > > The GNU Social Contract doesn't mention Maintainers, or any other > volunteer role. Could you say which parts of the GNU Social Contract > would block hackers working together on the GNU project in a loose or > rigid fashion? "It [the GNU project] commits to providing a harassment-free experience for all contributors." I'll refrain from addressing the latter portion at this time, since I expect it might prove contentious, but as things are, there is no single party that can commit to something, let alone provide any sort of experience with a single vision. regards, Andreas  https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-11/msg00274.html  https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-11/msg00341.html https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-11/msg00351.html https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-11/msg00306.html  https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-10/msg00011.html https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-10/msg00081.html https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-11/msg00188.html  https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-11/msg00388.html