Re: A summary of some open discussions

[Mark Wielaard]

Hi Andreas,

On Wed, 2020-01-15 at 11:32 +0100, Andreas R. wrote:
> On Wed, Jan 15, 2020 at 12:56:16AM +0100, Mark Wielaard wrote:
> > On Tue, Jan 07, 2020 at 04:24:44AM -0500, Dora Scilipoti wrote: 
> > > > Since Brandon was delegated by the FSF president to
> > > > appoint new (co-)maintainers [...]
> > > 
> > > Correction: Brandon Invergo was delegated by Richard Stallman wearing
> > > his Chief GNUisance hat, not as president of the FSF.
> > 
> > We cannot really know because he used to wear both hats and depending
> > on who you ask they'll tell you he made decissions as either Chief
> > GNUisance or as FSF President. If you say it was as Chief GNUisance
> > then it is a good question where that authority came from. 
> 
> As Chief GNUisance this should be quite obvious: because he started the 
> project.
> 
> The unclear option would have been if his authority had been derived from 
> being
> the president of the FSF, which is where the situation has changed.
> 
> > And whether
> > we still need a position like Chief GNUisance going forward. 
> 
> That doesn't logically follow and is basically a version of Cato's famous 
> "Furthermore, 
> I consider that X must be destroyed" [1] aimed at GNUisance's position.

That feels like a very negative way to think about evolving project
governance. As a project I believe we should think about and discuss
what has worked for the people doing the work in the past 30 years,
what works well, what doesn't work anymore, and figure out what will
work best for the next 30 years. Given the changes to the project, the
new (and old people) involved, and the the changes in authority, given
or earned, it is only natural to think about and discuss this for any
position in the project. I admit that is not always easy and sometimes
a little painful.

> Maybe it's time for those who desire change to post a clear set of goals and
> a roadmap on how to establish those goals so this governance discussion can
> continue in good faith.

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.

Cheers,

Mark