adding Governance.md, and testing a signed commit

[ionides]

A revised version of pull request #56, with the addition of a GPG signature

[kingaa]

The only thing I might say with respect to the governance rules is that the discussion of quorum and voting seems a bit strange with 4 core developers. I would support a consensus model. Alternatively, one could say that 3 of 4 core developers must approve any changes. Talking about a quorum is strange since that implies there would be a meeting that takes place at a definite time. While that could happen, I imagine that most of the time the discussion would be asynchronous and online and so the quorum would effectively be everyone, in which case a majority is 3.

Of course, if the core team were ever to get large, rules such as this would make sense.

[ionides]

The idea is to set things up so that a new person with a substantial professional interest in developing panelPomp can be invited to join the core development team without having to change the rules. As @kingaa points out, panelPomp may never acquire additional core developers, but maybe it will. I was writing these rules to use also for pypomp (https://pypi.org/project/pypomp/) which I think is more likely to grow. In particular, @kingaa and @cbreto would be very welcome to join pypomp if you find yourselves interested in it.

[kingaa]

The issue remains, though, that a quorum is only defined relative to a meeting. How about just simply saying a majority of core developers is sufficient to make a decision? Then the rules can remain unchanged even if the core membership grows.

[ionides]

Yes, let's change accordingly. I've avoided getting into tedious rules about voting and meeting procedures, which can happily be avoided in a small, friendly organization. However, the issue of whether the majority is required among actively participating developers or all developers is too basic to be avoided. My proposed rules were explicit that the majority is among voting and non-abstaining members as long as 2/3 engage. Requiring a strict majority of all members avoids the quorum issue, so it simplifies the rules. It has the slightly unfortunate effect that a temporarily non-participating developer effectively says "no" to absolutely every decision they are asked, rather than "whatever". There are benefits both ways, but since @kingaa prefers a strict majority of all members, and Occam's razor also comes down in its favor, let's do that.

[jeswheel]

@ionides, sounds like you're willing to accept Aaron's proposed changes, as am I.

Yes, let's change accordingly...

If this is the case, I think we can proceed with this proposed change to the pull request in two ways:

1. @ionides can modify their pull request to include the changes.
2. I could locally merge the pull request, make the changes myself, and then push to the repository and close this pull request.

Either way works for me, but let's get this pull request closed before making a release.

[ionides]

I made a modification which I think meets the consensus.