Maintainance and onboarding new maintainers

[marzer]

Sorry for the clickbait-y title. The @toml-lang org has three members, two of whom appear to have largely moved on to other things, leaving the language stewardship to fall more-or-less entirely on @pradyunsg's shoulders. These things happen, life is complex, et cetera. I'm wondering if maybe it's time to lighten @pradyunsg's load by adding some more maintainers to help with the backlog?

Or, alternatively, given that TOML has grown quite substantially in the last few years and the pseudo-BDFL model the language is currently using does focus the responsibility very much on one person, it might be time to reconsider it altogether. I don't have any domain experience to draw from here, so I don't feel as though I can offer any meaningful suggestions, but wanted to maybe stir up a little discussion in the area all the same.

[arp242]

Aside from what we do/don't want to do with this, I think at least part of the problem is that Pradyun doesn't actually have the permissions, judging by: #585 (comment)

[marzer]

Ah, good point. That certainly seems like a problem worth addressing! cc @mojombo

[pradyunsg]

Yea, I don't have the relevant permissions to change the bus factor here. :)

[ChristianSi]

I agree that one or two additional maintainers with more time on their hands and the right to make decisions at least in the absence of reactions/objections from the other maintainers would be great. PRs often go unreviewed and unmerged for months, sometimes years. That's not a good situation.

Now the primary question, I guess, is: any volunteers?

[marzer]

Now the primary question, I guess, is: any volunteers?

I'm on github for various reasons pretty much every day so I'd say I'm active enough to help out with basic issue triage and reviewing 'simple' PRs. Not sure I have the temperament for more in depth arbitration, so others are welcome to step up for that role 😅

Ultimately it's moot if @pradyunsg can't endow others with maintenance powers though...

[eksortso]

Now the primary question, I guess, is: any volunteers?

My schedule wouldn't allow for full-time maintenance duties. But I could be drafted into part-time if there were two other active maintainers. It falls in line with how I think the project ought to be run.

Let's talk polity for a bit. I think a bus factor of 3 active maintainers is best, and for now, the current three can choose who the active 3 will be, and agree to have them listed somewhere we can point to if anyone wants to promote a discussed idea or merge a PR, and wants to know who to contact to make that happen. (We need that list because it comes up a lot at the ends of our conversations.)

TOML is at v1.0.0 with additional changes on the way. We need stability as much as change. I think @pradyunsg has done a great job putting on breaks and keeping discussions on point. Any maintainer needs that same skill. One say no, things get pushed back. The personality at play in situations like this needs to be diplomatic at least.

For change, having more maintainers would mean, occasionally, civil disagreements. But, there are no hills to die on here. If an issue's proposal or a PR gets assent from at least two maintainers with no objections from the third, then it ought to be moved forward. They'd put this in writing, of course.

But most importantly, we need it made explicit if more discussion would be required before things get moved forward or back. So good maintainers need to spur on debate or action when things reach a standstill. We need their comments, too, basically. That's a skill, and it would help us bring new perspectives to the table when exercised freely.

We haven't heard much from @mojombo recently, but even with more hands, he would most certainly have the same powers as any of the active maintainers.

Not singling Tom out for any explicit purpose, though it is his language, and he gets a say by virtue of emeritus. But it's just I don't know who the third maintainer currently is.

[ChristianSi]

I think @eksortso would make a great additional maintainer! And @marzer too, if he can be convinced to do it.

I hope that if we, @pradyunsg included, can reach an agreement on who the additional maintainers should be, then @mojombo or whoever else has has that right (if anyone) could hopefully be convinced to step out of retirement for a minute to hand out the necessary permissions.

[eksortso]

Thanks, @ChristianSi . I can be drafted to serve. I'm willing.

Who is the third maintainer right now? Is it written down anywhere? @mojombo and @pradyunsg are maintainers, of course.

You have been very involved. Could you volunteer?

@BurntSushi has been deeply involved, but to what extent recently, I'm not sure, because I'm not involved with the testing suite.

[eksortso]

@marzer I agree with @ChristianSi, you would be really good at this.

[ChristianSi]

@eksortso

You have been very involved. Could you volunteer?

I'm happy to continue just as a commentator and reviewer, but yes, should I get the honor to become part of a maintainer team, I wouldn't reject it.

[ChristianSi]

What's the status of this? Has the TOML spec become abandonware? Sadly, right now it feels a bit like it has.

[pradyunsg]

The status is unchanged -- @mojombo is the only person with admin access, so someone will have to ask him to action on this.

[pradyunsg]

The spec is certainly not abandonware -- I've had limited time to look at the discussions here, not helped by falling sick and all that.

[mojombo]

I will be happy to put together a conversation with active members and figure out a path forward for a team of maintainers.

[ChristianSi]

@mojombo Any news on this one? It's been more than half a year now since you promised to figure out a path forward.

[mcarans]

@mojombo May I ask if there has been any progress in onboarding new maintainers?

[ChristianSi]

Yeah, that's an excellent question! Frankly, adding two or maybe three additional maintainers out of the short list of core contributors shouldn't be rocket science, especially considering that there seem to be some volunteers. And it sadly has become clear enough that TOML isn't going anywhere before this issue is resolved. @pradyunsg does excellent work when he's around, but the two or three hours a month he seems to be able to invest simply aren't enough to resolve all the open issues that have assembled by now.

[mcarans]

In case of interest to watchers of this issue, there's a discussion going on which may interest you and where your input would be welcome: https://discuss.python.org/t/toml-development-has-stalled-implications-for-pyproject-toml-and-a-way-forward/

[eksortso]

In case of interest to watchers of this issue[...]

@mcarans The implication that TOML development has stalled is an outright lie, which I hope you intend to correct.

[mcarans]

@eksortso By development I was including the whole process including maintenance and release. I made it clear in the post that the problem is that new maintainers cannot be added as this issue makes clear and I linked here, so I doubt there would be any confusion. I realise that people have been working on different PRs. It is getting those into a completed 1.1 release that looked like it had stalled.

[ChristianSi]

It's not true that new maintainers cannot be added, though. It's true that it hasn't happened yet, but I still hope it'll happen in the future!

[mcarans]

I have in any case added a comment at the end which clarifies (I cannot edit the title or original post unfortunately) and I am sorry I wasn't clear from the beginning @eksortso .

[ChristianSi]

@mojombo @pradyunsg Any news on this one? Is there a chance that TOML will be again properly maintained in the new future?

[pradyunsg]

No news from my end -- I'm spread relatively thin across my current OSS stuff, and for TOML, I don't have the ability to onboard new folks (no admin powers on Github).

[ChristianSi]

@pradyunsg You don't have the right to give others maintainer status, sure. Nevertheless I think there is something you could do to get this finally moving. Clearly @mojombo lacks the time to find any additional maintainers on his own, but if you assembled a short list of two, three, or four people to be promoted to maintainer status for him, that could be the decisive step to overcome the logjam. @mojombo will still have to do the actual promotion, but that would be so much easier if all the work were laid out for him.

[mojombo]

I've given @pradyunsg full admin rights on the org.

[pradyunsg]

And, I can confirm I have them. :)

---

Thanks to a long weekend, I've finally found a bunch of time to review a lot of the open issues; as well as spend some time thinking about how to onboard new maintainers to the project.

This language has been operating on a somewhat autocratic decision making model (I wouldn't go so far as to call is a BD model even honestly) and I'd like to move away from that -- as part of adding new maintainers, I think I'd like to move to a more concensus-driven model.

One unwritten thought process I've had around the language is is that adding more things isn't necessarilty going to make the language better, but it is going to make the language bigger -- and a bigger language is inherently more complex. I'm somewhat wary that we'd lose this with a concensus-driven model but also optimistic that we'll navigate that well-enough. :)

---

OK, so... In the spirit of not doing things too hastily, I guess I should ask: do folks have any opinions how we should organise ourselves here?

• How to decide on who to add as a maintainer?
• Have a single "flat" group with power over everything, operating on concensus?
• Have separate groups for making spec decisions, maintaining the compliance test suite, and maintaining the website?
• Do we want a BDFL-esque role that allows overriding decisions made through concensus? (like Jupyter's model)
• Keep all the existing non-active maintainers around with the same powers as other maintainers, moving them into relevant teams?
• Move existing non-active maintainers to an emeritus team, from which they can move back whenever they want?

The least-infra model is keeping things as-is, i.e. every maintainer has write access to all repositories in the organisation; and we operate on concensus that isn't systemically enforced.

[arp242]

To be honest I think the current model has been working reasonably well:

• Someone proposes a change.
• People discus.
• Pradyun reads discussion after it slowed down and decides.

It's not that I think Pradyun's opinion is better than anyone else or that I agree with all his decisions, but having one single "decider" has its value.

The downside is that sometimes all of this takes a long time and puts a lot of responsibility on Pradyun (which he may not necessarily be happy with, which is the vibe I'm getting from his comment here), but TOML doesn't need to move at a fast pace and this process is free of bureaucracy and drama, so in general, I'm fine with things as-is.

Do we want a BDFL-esque role that allows overriding decisions made through concensus? (like Jupyter's model)

No matter what, I would definitely be in favour of that.

Have separate groups for making spec decisions, maintaining the compliance test suite, and maintaining the website?

Should this be moved here, I think it makes sense to give "collaborator" rights to me, as I currently have on BurntSushi's repo, to allow me to merge PRs, fix stuff, close issues, make new releases, etc. in a timely fashion.

I don't think we really need a process or anything beyond that: this has worked well for the last few years and it's pretty low activity in general; nothing really gets "decided" here beyond technical stuff on how to organise the tests and such; it's not a fertile ground for great controversy or disagreement.

If anyone else also wants commit rights then I don't mind that either; I'd welcome other people wanting to help.

[ChristianSi]

@pradyunsg That's excellent news! My answers to your questions:

How to decide on who to add as a maintainer?

I suggest to check who are the most active contributors and ask them if they are willing to become maintainers. Once there is a group of three or four, that's probably enough. (And it shouldn't be much more than that, to avoid overcomplicating things).

Have a single "flat" group with power over everything, operating on concensus?

I would be a bit skeptical about requiring consensus since that would mean that any single maintainer could block all decisions. I'd rather say something like: "Consensus is strongly preferred, but if it can't be reached, then a majority of two thirds of the maintainers is sufficient to move forward." (As usual, abstentions wouldn't count.)

Have separate groups for making spec decisions, maintaining the compliance test suite, and maintaining the website?

I'd say if specific maintainers focus on specific areas, that's fine and they'll naturally have more authority in that area because of their experience so the others are likely to take their view particularly seriously. But I wouldn't give anyone formally more rights in any specific area than the other maintainers – that would only needlessly fragment the group.

Do we want a BDFL-esque role that allows overriding decisions made through concensus? (like Jupyter's model)

What do you mean by "overriding decisions made through concensus"? If there is consensus, that would by definition mean that the "BDFL" agrees as well (or at least doesn't disagree), so that issue could never arise. Right? But if you mean whether anyone should have the right to override decisions made by majority, I'd say, no. Consensus is best, but a majority is still to be respected.

Keep all the existing non-active maintainers around with the same powers as other maintainers, moving them into relevant teams?
Move existing non-active maintainers to an emeritus team, from which they can move back whenever they want?

If a maintainer completely disappears, say for a year or longer, I'd say it would make sense to move them to such an "emeritus team" and for the time being remove the maintainer flag from their account.

And of course the issue may arise that someone wants to give up the maintainer role, say because of too many other obligations. That shouldn't be a problem. But I would suggest keeping care that the number of active maintainers doesn't fall below three.