Stdlib: Governance

[zbeekman]

Governance

I feel that it is important to have some sort of formal governance. This should be in place in advance of when conflict arises, which is when you actually need it. While this issue is related to #5 (workflow), it is, in my opinion, distinct.

A case study

I was invited to be a Mac Homebrew maintainer in July 2018 right before a period of drawn out conflict mostly between a very active maintainer and the projects "Lead Maintainer". In addition, this conflict was born out of a technical issue with vocal users and contributors fanning the flames. If the organization had a more formal governance model then:

1. The decision making process for technical decisions would have some basis in a pre-established framework and therefore appear less arbitrary and personal
2. A formal procedure would have been in place for resolving both technical and personal conflicts

Within 6 months the organization had its first ever in-person meeting, which I had the pleasure of attending, and ratified more formal bylaws. Since then I have never seen the same level of conflict between maintainers, or between users/contributors and maintainers (or the project itself).

Issues to be addressed in bylaws or less formal governance

An imperfect list of the questions that need to be answered follows.

1. How are controversial decisions made? Who gets the final say?
2. Should there be a technical steering committee? Or a project leader? Or both
3. What sort of decisions should be put to a vote among some sort of membership?
4. How are differing levels of responsibility defined?
5. What is the fortran-lang's formal or informal relationship to J3/WG5?
6. How can we setup an infrastructure and process to ensure the continued health and enthusiasm about this project as it (hopefully) grows?
7. How can we divide responsibilities amongst maintainers and contributors to ensure that important decisions don't get made under the radar, while ensuring that there is little to no unnecessary duplication of effort and reduce/prevent bikeshedding.

Caveats

Of course this is a very new & young project, and as such adopting formal bylaws is probably overkill. It's certainly not fun, and too much bureaucracy can certainly be harmful. But, giving people a framework for how decisions are made and finalized---especially controversial ones---makes the outcome easier to understand and tolerate when it isn't in your favor, and having a process to deal with controversial decisions and conflict is very nice to have BEFORE you need to use & apply it.

[certik]

Currently until we build a community, the very last decision will be made by Milan and I. We promise to do our best to never actually need to use that power, and instead provide the platform and moderate the discussion so that all big decisions are made by community consensus.

We do not need other bureaucracy right now.

On Tue, Dec 31, 2019, at 11:44 AM, zbeekman wrote:

Governance

I feel that it is important to have some sort of formal governance.
This should be in place in advance of when conflict arises, which is
when you actually need it. While this issue is related to #5
https://github.com/fortran-lang/stdlib/issues/5 (workflow), it is, in
my opinion, distinct.

A case study

I was invited to be a Mac Homebrew
https://github.com/homebrew/brew#who-are-you maintainer in July 2018
right before a period of drawn out conflict mostly between a very
active maintainer and the projects "Lead Maintainer". In addition, this
conflict was born out of a technical issue with vocal users and
contributors fanning the flames. If the organization had a more formal
governance model then:

1. The decision making process for technical decisions would have some
   basis in a pre-established framework and therefore appear less
   arbitrary and personal
2. A formal procedure would have been in place for resolving both
   technical and personal conflicts
   Within 6 months the organization had its first ever in-person meeting
   https://brew.sh/2019/06/14/homebrew-maintainer-meeting/, which I had
   the pleasure of attending, and ratified more formal bylaws
   https://docs.brew.sh/Homebrew-Governance. Since then I have never
   seen the same level of conflict between maintainers, or between
   users/contributors and maintainers (or the project itself).

Issues to be addressed in bylaws or less formal governance

An imperfect list of the questions that need to be answered follows.

1. How are controversial decisions made? Who gets the final say?
2. Should there be a technical steering committee? Or a project
   leader? Or both
3. What sort of decisions should be put to a vote among some sort of
   membership?
4. How are differing levels of responsibility defined?
5. What is the fortran-lang's formal or informal relationship to
   J3/WG5?
6. How can we setup an infrastructure and process to ensure the
   continued health and enthusiasm about this project as it (hopefully)
   grows?
7. How can we divide responsibilities amongst maintainers and
   contributors to ensure that important decisions don't get made under
   the radar, while ensuring that there is little to no unnecessary
   duplication of effort and reduce/prevent bikeshedding
   https://en.wikipedia.org/wiki/Law_of_triviality.
   Caveats

Of course this is a very new & young project, and as such adopting
formal bylaws is probably overkill. It's certainly not fun, and too
much bureaucracy can certainly be harmful. But, giving people a
framework for how decisions are made and finalized---especially
controversial ones---makes the outcome easier to understand and
tolerate when it isn't in your favor, and having a process to deal with
controversial decisions and conflict is very nice to have BEFORE
you need to use & apply it.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/fortran-lang/stdlib/issues/59?email_source=notifications&email_token=AAAFAWDJFGPWGEZ27UVOVXTQ3OHJXA5CNFSM4KBXKMIKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IDQSKXA, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAFAWDRB23YY2RPMTZS7MLQ3OHJXANCNFSM4KBXKMIA.

[zbeekman]

Currently until we build a community, the very last decision will be made by Milan and I.

Great to know! At the very least letting people know this is helpful. Thanks!

[zbeekman]

After considering this further and a high bandwidth discussion with Ondrej, I think it makes sense to table this discussion for a while until we’ve gained a bit more momentum. I’ll leave it open as a reminder, but won’t be hurt if others feel it is a distraction and want to close it.

[certik]

For now I think our current arrangement is good enough to allow us to both deliver and build a community and once our community grows and we build trust to each other, we can figure out more a formal structure later. For example I would like more serious approvals once we start moving things from "experimental" to "main", hopefully involving the J3 committee at some (perhaps informal) level. Right now we are in the "experimental" phase, and there our less formal arrangement should allow us to deliver. And if there are any disagreements, we can do a conference phone call, or even meet later on at some conference, and I am positive we can resolve any such differences.