[GOV] New governance for aeon

[TonyBagnall]

hi, what do you think we should do with sktime governance? Personally I would like to scrap it all and start again, but htat might be too disruptive?

The current governance roles are:

• Core developer
• Community council (CC)
• Code of conduct committee (CoCC)
• Algorithm maintainer (in codeowners file)

[MatthewMiddlehurst]

See #20, #21, #22, #23

[aiwalter]

I am in favor of developing in small junks to our target. Like making small PRs with a dedicated and isolated change as in my above linked PRs

[MatthewMiddlehurst]

Not much discussion in this issue so far, so I'm going to post notes and my opinion on some of the current and potential roles. I will preface this with saying I'm not that interested in breaking new ground in governance compared to other projects, nor do I really see the need to. While writing this I looked toward the governance documents for SciPy, NumPy, Jupyter and Scikit-learn.

Benevolent Dictator for Life (BDFL)

Not a role in aeon. SciPy has a formal BDFL and Jupyter formerly had a BDFL.

Would maintain sole ownership of the repository and other accounts. Formally in a position to break ties (or basically just be a dictator as the name implies)

Probably not a very popular opinion as pointed out by @ltsaprounis in a previous meeting, but It may be safer to have a single person as dictator formally rather than informally or having multiple people in position to remove access to accounts. If this was accepted, I assume it would be on the understanding that it is not permanent.

Community Council (CC)

Current leadership, similar to Technical Committee in Scikit-learn.

Made up of Core Developers, has additional responsibilities including conflict resolution, technical leadership, project management and reserves veto rights for all decisions.

A role (or roles) for wider project management are required somewhat for the responsibilities stated above, but currently the role makes the governance of aeon more hierarchical than it needs to be. I don't think the CC needs the ability to veto any decision or make the final decision if a vote fails to reach 2/3. Scikit-learns Technical Committee sounds like the much more tame version, where they engage in consensus seeking and have the ability to lower the Core Developer vote threshold if required.

Core Developer

Current role which is functionally the same as the Scikit-learn Core Developer role, comparable to the Steering Council in SciPy/NumPy.

Has voting rights for project decisions. Has write access with the ability to interact with the repository, review and merge PRs.

I think this role is fine as it is currently, but agree with @lmmentel's opinion given in a previous meeting that the bar to becoming a Core Developer could be lowered (i.e. #134 or other algorithm implementations, given they want to continue contributing). There is no formal set of requirements to become a Core Developer currently other than a recommendation and a vote, which should probably remain, however.

Code of Conduct Committee (CoCC)

Current decision makers for CoC complaints. Jupyter has a Code of Conduct Committee (in a separate document).

Has access to CoC complaints, discusses with people involved in CoC complaints and makes a decision regarding CoC complaints.

Like core developers, I think this role can remain the same/similar. Maybe less talk about enforcing the CoC as it A. sounds rather hostile like they are police officers or something, and B. is not very practical in the grand scheme of things. Seems fairer for the role to provide a decision and recommendation for the broader community to act on.

The role is heavily intertwined with the CoC itself which should be slimmed down IMO, but that's another discussion (#35).

Algorithm Maintainer

As far as I am aware, none of the linked organisations have an algorithm maintainer role or anything similar.

I don't think this role should exist, to be honest. If you have an interest in an algorithm and someone wants to make changes to it, review it normally. If you want to be notified of changes, add yourself to CODEOWNERS. There is no need to have formalised mini-dictators for each estimator.

[MatthewMiddlehurst]

IMO we should retain the CC, CoCC and Core Developer roles from the previous governance with a less powerful CC. I have drafted a slimmer governance document in the style of Scikit-learn to this effect.

None of this is set in stone and I can just close the above if we want to go in a different direction.

[ltsaprounis]

Just putting it out there, but I think going for a BDFL might be a good option, you can't have many captains in a boat. Of course I'm out of any consideration because I'm the first who said it 🤣

[MatthewMiddlehurst]

I think BDFL has its benefits, but I think the package has too much of a split focus for a candidate to be selected without someone taking issue, personally. That discussion can wait to be had only if everyone decides a BDFL is necessary, however 🙂. I think it will add too much of a role hierarchy for most though.

[TonyBagnall]

I'm not sure we really need the BDFL role(s), at least not atm. The schism was not about code. My preference would be to move forward with a lightweight governance along the lines of scikit learn, remove hierarchy, and see where it takes us.