APE0: the Astropy Project Governance Charter - #61

I just did a bit of thinking and research and I wanted to report back. While I don't like the ring of "Bylaws", I agree that this document is most appropriately called the Bylaws. (We do not have a Charter because we are not actually a legal entity.) So, I retract my objection to calling this document our Bylaws.

@eteq - why did you change to bylaws-not-bylaws? Given that @kelle has retracted her objection, can you just change back to bylaws?

@astrofrog - oops! I forgot to leave a message here about how that happened when I first merged it: in eteq#1 @nicole-numfocus said this in eteq#1 (comment):

The only change I did make was to remove the term "ByLaws" and replace it with "policies" throughout the document. (Though this should not have much of an effect on the substance) This term cannot be used because it is a term with legal connotations for NumFOCUS. "policies" can be changed to some other term if the community desires.

I thought "policies" is definitely not what we wanted given the WG discussed policies as applying in different contexts. So my intent for {bylaws-not-bylaws} was to allow there to be a discussion here about what we wanted to do about that in this PR. The use of {bylaws-not-bylaws} instead of some other choice was because I found "bylaws" and "policies" to be a surprisingly difficult find-and-replace, and I knew that string would be unique until we pick a suitable option. If we say bylaws is a non-option based on NumFOCUS's legal analysis, then I'd say I like the following in my preference order:

1. "Social compact"/"compact" - (definition: an implicit agreement among the members of a society to cooperate for social benefits, for example by sacrificing some individual freedom for state protection. )
2. "Governance"/"governance pact"
3. "Governance"/"governance rules"

I vote for "governance charter"

I agree with governance charter.

If possible can you wrap the text to make it easier to comment on specific lines? (some paragraphs are actually wrapped but just with very long lines)

Governance charter is good for me too, so I put that in as a tentative choice so that there is not something waiting for discussion. With this I think this is ready for broad review, so I will turn it from draft into "regular" PR and announce in the regular channels.

I like the document very much.

My one slight nick, more future-proofing than anything else, is the voting system - something based on voters giving an ordered list rather than N names for N positions tends to give results that more people are happy with.

One solution would be to make the actual voting system a bit less explicit, i.e., leave that as an implementation detail for later (implementation might also need to include, e.g., how candidates present their ideas for what they would want to do on the coordination committee, how much time they have, etc.)

I think that the "initial voting members" are a bit too restricted, since it relies mainly on participation in telecons and such -- IMO this should be much broader, involving almost everyone active in the project.
My reference here is Debian, who elects its leader by voting from all Debian Developers, and this process works quite well.
Disclaimer: I am affected by this rule.

Another point (also copied from Debian structure): Candidates for the council should make a statement of how they see their role in the CC during the next election period and what they are planning to do/reach. Such a statement should accompany a self-nomination resp. the acceptance of a nomination. BTW, maybe only allow self-nominations? Nominations by others anyway require an acceptance step, and then the nominee could also just have nominated themself.

Should the CC also be responsible for maintaining relations to other projects and groups? Like IAU, FSF or so?

@mhvk Debian uses the Condorcet method for almost all votings, which works quite well. The major drawback that I see is that the vote report is a bit complicated, see this example from 2019 where we had four candidates for our leader.
I personally like it, since it gives a very flexible way to express the vote, but others may think see it too complicated.

@olebole - the matter of the initial voting members is a difficult one and has been the subject of many many hours of discussion :) The current suggestion is really just for the initial members and the idea would be that this could almost immediately be increased by vote - for instance you should definitely be added to the voting members in my opinion.

Having said that I do agree with you that focusing exclusively on telecons might not be quite right - I think we should broaden to say 'has a named role and is active on one or more communication channels such as telecons, mailing lists, and/or GitHub' (which would include you) and make sure that remote participation in coordination meetings counts.

Jus to be clear, some votes might also be put to the community as completely open votes - but we need a more restricted group of active project members to direct things to avoid getting derailed by other large groups or consortia not previously involved in the project.

To add just a bit more from what @astrofrog said in response to @olebole's point about the voting members: the intent was that this document specify the initial members and that there be a round of the initial members pulling people in before any first votes for the CoCo happens - indeed the point is that it's hard to initialize because we don't have a clear definition of who's a "developer", but it's much easier once the first cohort is in to say "Yes, @olebole has clearly contributed to the project in a substantive way".

However, I'm realizing that is not explicitly stated anywhere. We could update the document to explicitly say that at least one round of bringing-in-new-voting members is required before any other votes occur? That would make this clearer - do you think that would help @olebole?

Oh and on @olebole's other points:

Another point (also copied from Debian structure): Candidates for the council should make a statement of how they see their role in the CC during the next election period and what they are planning to do/reach. Such a statement should accompany a self-nomination resp. the acceptance of a nomination.

This is a good idea! My one pause is that I'm not sure if we should put it in this document, following @mhvk's point of not over-specifying the implementation details? But I could go either way with a concrete wording suggestion...

BTW, maybe only allow self-nominations? Nominations by others anyway require an acceptance step, and then the nominee could also just have nominated themself.

The WG discussed this and the intent of allowing others to nominate is to make it easier for people that are more outsiders (e.g., representative of the user community) to be easier to bring in. One of the big concerns the WG had is the possibility of the voting membership model leading to a more insular and less diverse community, and self-nomination reinforce that because for some people otherwise well-suited, Imposter Syndrome is a serious concern. Others-nomination is a potential antidote to that.

Should the CC also be responsible for maintaining relations to other projects and groups? Like IAU, FSF or so?

I also think this is a good idea to add in the list of roles, but I want to be careful not to imply that this means non-CoCo members should not also help maintain relations. That is, I think part of Astropy's magic is that we are all diplomats for the project at some level (see for example the instrumental role @bsipocz took in starting off the Moore grant process). But I agree it makes sense for the CoCo to be viewed as the "institutional" contact for when specific instutitons feel they need to talk to someone "in charge"/"representative of the Project".

On second thought, I think it makes sense to put in the suggestion that candidates are expected to provide a brief statement, but perhaps keep what is expected to be in it a bit more free (goals, time commitment, etc.).

And 👍 to the logic for allowing both nominations by others and by oneself.

I think a lot of this looks good. My main concern is that the criteria for being able to vote seem overly restrictive. I recognize that there may be a practical need to impose some criteria and don't have well-developed suggestions off hand, but AstroPy has been very open and consensus-based until now and I'm concerned about not including everyone with a legitimate interest (and perhaps even becoming more cliquey, which I think would be harmful, especially when we clearly still don't have all the resources we need). To be clear, I am not arguing that core members should have to consult the community on every decision they make in their leadership roles. I'll leave a few comments on smaller details in line. Just my 2c (sorry I didn't pick up on some earlier discussion in October).

@jehturner - regarding the voting members, I think we are far enough in the process of review of this APE that we can't change this as we otherwise have consensus, but just to be clear, the plan was always that some votes would be put to the community. But you can't have something like the CoCo be elected from anyone in the world, otherwise you could end up with some random large collaboration or institute being able to push one of their people onto the CoCo even without prior involvement in astropy. So for the purposes of governance the list needs to be restricted somewhat. It's also important to note though that the pool of voting members will grow over time so even with this initial restrictive group, there may be over a hundred voting members in 10 years.

The CoCo met today and approved this PR! 🎉

I plan to draft an email to outline next steps and so on, so the final merge will be awaiting that, but the text itself is approved and ready to go.

I have now updated the APE to indicate that it is accepted and filled out the decision rationale. Merging! 🎉