Mastodon project governance


#21

I think it’s seriously time for us to really have a discussion about Mastodon’s governance. We didn’t make any progress at all in the past year and I think, at this pace, we are going to face a real governance problem sooner or later.

First and foremost, I want to make it clear that this post isn’t intended to be a personal critic against you @Gargron: you always seemed like a really nice person to me. Besides, this isn’t about the quality of your work nor your dedication to Mastodon either. We all saw how hard your work on it and how passionate you are about it. If it wasn’t for you, none of us will be here.

General problems

During the past few months, I saw a lot of people who contribute to the project being unhappy with how things are going. Based on what I saw, the most common complaints seem to be:

  • A lot of pull requests are just laying around, sometimes since more than a year, waiting for someone to review them or for Gargron to merge them.
  • More generally, the GitHub project seems under-maintained. Most issues aren’t properly tagged anymore and almost all pull requests aren’t.
  • There’s doesn’t seem to be any mid-term or long-term goals for the project. There used to be project boards for some of the earlier versions, but it’s been months since a release had one. Besides, even when they were a thing, releases were usually shipped before the project goals were all reached.
  • Some developers seem to find it difficult to discuss with Gargron.
  • mastodon.social’s moderation team seems understaffed. Aside from Gargron, who already has a lot on his plate when it’s come to Mastodon, there is only three moderators. As of today, with almost 160,000 users on mastodon.social, that’s a ratio of 1 moderator for 40,000 users.
  • The project management is really unintelligible, even for invested users like me. For example, after Maloki first departure, some months ago, a Community Manager was named. After the first weeks, I never heard of her anymore. Since there is no team page and since the announcement of her nomination wasn’t even published on the official Mastodon account, I never managed to find what she was up to. I recently learned that her contract only lasted a month or something and that there was no replacement.

Maloki’s recent departure

Aside from the above points, something really puzzles me: the circumstances of Maloki’s recent departure.

Some context: last year, following some events of which nature I don’t remember exactly, it was decided to create a new role inside the Mastodon project: Project Manager. Maloki was then hired by Gargron to fill that role. Sadly, some months later, she had to resign for personal reasons. The Project Manager position then stayed vacant for quite some times. But last month, she announced being rehired as Mastodon’s Project Manager.

However, she announced yesterday, that her contract won’t be renewed after the end of the month. It seems this sudden announcement is, at least partially, the result of a misunderstanding between her and Gargron. Nonetheless, I still have a few questions about this:

  1. What was the point to rehire a Project Manager for only a month? Was it planned to renew her contract but that was finally not possible? And if it wasn’t planned, why rehire someone on the first place?
  2. I can get there was a misunderstanding on the contract duration, but why is this misunderstanding only cleared now, almost at the end of the contract? I’m puzzled at how this wasn’t brought before between Gargron and Maloki during the time they were working together. I would also like to point out that this leaves a worker without a job on a very short term.
  3. Is it planned to hire a new Project Manager? And if not, why? Are the problems the introduction of this position was meant to solve not actual problems anymore?

What to do from now?

I suggest we put a proper governance in place. Whatever is the governance model we choose, it needs to account that there is different aspects to the project (development, community management, mastodon.social…) and different populations (developers, instance’s admins, end users…) that may have different needs.

I suggest everyone to take a look at Debian’s constitution, not because I think it’s the model we need to follow, but because I think it has the kind of formal writing we should expect to such a document.

I’m sorry, I had a lot of other things to say, but since my English is getting worse and worse as I write this, I think I’ll stop here for now.


#22

Wow, I’d like to read what @Gargron has to say about this because it seems so chaotic.

That said…

I did not read the Debian Constitution until about 3 years ago and then I was very disappointed by it. It came from a time (1998) where the open-source community was booming, and indeed it conveys a very rigid and limited view – as in: apolitical. So I started drafting another version that places the politics of free software at the center of the reflection, at a time when Devuan had the chance to ‘reboot’ the community process after the fork away from Debian. You can read the draft here, it’s full of holes, but there’s enough to get the gist of it. The principles set forth in this draft are complemented in the software freedom, your way booklet. I’d love some comments, from any side :slight_smile:


#23

I have limited time right now so I cannot address everything in this thread, but I wanted to get something out about some of these things:


This situation is slowly improving and the backlog is clearing up. I try to be more welcoming and to merge even things where it doesn’t, in a practical sense, make sense to touch the code. But I am very picky about the quality of features and architectural changes and especially UX changes. Every code submission has a maintenance cost, even if no other costs are apparent. And the result, the Mastodon that you see, is a result of that pickyness.

As far as I’m aware almost all pull requests are tagged. A lot of the issues aren’t, that’s true. Here’s the deal with GitHub issues: There’s just too many of them. It’s not indicative of what needs to be done, what needs to be fixed, or the progress of the project. Anyone can submit an issue, and so a lot of people do. There are duplicates of existing bug reports and feature requests, there are questions, there are very specific errors related to deployment mistakes. From the perspective of purely development, that’s noise. And feature requests. A lot of folks have ideas for what Mastodon should be, but it can’t be all that at the same time. Just because there’s an open feature request doesn’t mean it’s planned to be done (but it may be). On the other hand, I do not see the harm in keeping them open - it gathers discussion that might change my opinion in the future, and to some extent prevents people from creating even more duplicates.

Occassionally in the past I’ve gone through all of them - from first to last page - to clean them up. Managed to bring the number from 700 down to 400. Then another wave of new users arrived, and the number jumped up to 900. Now I’ve brought it down to 830. What I’m trying to say is that it feels like futile work. I look at the issues that appear in my notifications, I look at issues that admins report to me personally, I sometimes just browse all of them regardless of any tags, and most importantly I do what I planned anyway. And again, from a diplomatic perspective, it doesn’t make sense to close feature requests if you might change your opinion in the future based on the discussion inside.

I don’t see why you should care if there’s many issues or pull requests open, to be honest. I am more suspicious if I look at a project and it’s got 0. A high number like ours means that people actively use the software. (And for comparison, not so many open-source projects are end-user facing like ours. It’s a totally different volume of attention)

A look at the insights tab of the project will reveal that in the past month, 194 pull requests were merged and 181 issues were closed. That’s not “undermaintained”, in my opinion.

Yeah I don’t use GitHub Projects. Tried it, didn’t stick. Mostly 'cause the UX is weird. I can’t put GitHub issues on that, as per above explanation, a lot of them are not relevant and the ones that are might be oddly named. There’s also the whole deal with whether you put issues or pull requests on the board. It’s weird. For particular releases, I’ve taken to creating a “Bump version to x.y.z” pull requests that contain a checklist that links to either issues or pull requests that need to be fixed/merged. But this is only required if there are many loose ends.

For the past couple months I have been working down the roadmap that I posted in the development Discord. Here is a screenshot:

Yeah, I know it’s not public. I do not, in fact, like the idea of committing to a public roadmap because I take a lot of detours based on what’s happening at the time. For example in 2.4, a lot of the features and fixes were addressing issues that sprung up with the appearance of Switter.at, the incredibly important Web Push API stuff was brought up by Dag Agren’s development of his app, performance-related fixes were discovered with admin feedback, etc, all things that happened spontaneously.

Furthermore, our release cycle is not based on features or fixes (because those arrive rather steadily, all the time), bur rather on time: We try to prepare a release every 30-40 days so that admins can benefit from the improvements as soon as possible. 30-40 days of development time, then normally 7 days of release candidate phase. In the current case of 2.4.0, the release candidate phase took 15 days.

I’m sorry to hear this. I actually don’t bite. I can be picky, maybe stubborn, but I am never rude to contributors, never take things personal, there is no risk in talking with me. On the other hand, I can give the most realistic feedback because I am aware of all the internals of the project, all challenges, I’ve participated in designing the protocols that we use, and I remember past discussions. At the end of the day, if you don’t like talking to me… Talk to your instance admin, talk to nightpool, yktzs, unarist or akihikodaki. There’s a large selection of people who can pass it on to me.

If my mods ask me to hire more help, I will do so. So far, that has not happened. Even with all the registered users, on a good day there’s like 3 reports to deal with, on a bad day maybe 40. Well within the means of 3 people, especially of most of the reports are simple spammers who do not require any discussion to deal with.

Yeah, this is true. I can’t comment on that too much, but essentially that person found another job only a few weeks or less after we signed a contract, so she ended up doing very little. In the grand scheme of things I don’t think that matters. I occasionally commission an artist to draw illustrations for the project, that animated video, sometimes pay for copywriting services, it doesn’t necessarily warrant announcing in my opinion. Of course, a permanent addition to the team would warrant an announcement, but so far it has not been the case.


The contract was written for one month, and we specifically discussed it such that the hours required for the job would not interfere with her existing studies/employment. Let’s be clear here that I am not leaving anyone out on a street.


Sorry if this doesn’t answer everything at the moment.


#24

Just a passing user but…

I have no real idea where to go to offer my time and non-technical skills.

(No disrespect to anyone but) even though I love the fediverse and would like to give back somehow, I’m probably not alone in seeing drama and thinking “yeah, nah”

Discussions of a governance nature are basically futile without Gargron’s approval, which I haven’t seen, so unless someone forks this and takes a decent number of instances with them which I don’t see happening then people are putting the cart before the horse.

Discussion beyond that (like delegating control of mastodon.social or assembling a team to get the github issues categorised, merged, etc) are just hot air before there’s a constitution or whatever and subsequently a decision-making body.

Feel free to tell me all the ways in which I am wrong


#25

Thank you @Gargron for taking the time to respond so thoroughly. I’m very glad you take all this so seriously and frankly I’m totally supporting your fantastic effort. I hope that you’ll take the time off you deserve and seem to have decided to take, even if that means fighting your urge to code :slight_smile:


#26

Why do you think a fork is the right way to do this?


#27

I do not think that.


#28

Then I didn’t get you right. Can you expand your thought?


#29

I’m saying much of this is just bikeshedding. The relative merits of constitutions, where to set up a foundation or incorporate or some other structure and things like that. There’s an obvious process to follow. This is basically Gargron’s show at the moment as far as I see (not in the discord or checking the github or whatever but that is my impression) and if he’s not happy with a proposal then options are limited to either accept that or fork off. And so on.


#30

To be plain, if Mastodon is to be a long term project servicing w community, it needs to be more than a one man show in terms of governance. It must have a directing board that is selected in a reasonable way, which includes managing hiring and contracts as well as sys admin and mods for the m.s server. It is a standard problem with an essentially standard solution.

If it is a one man show, then eventually Gargron will move on(possibly burnt out and sick of people asking him to do things) and the project will end & mastodon.social will shut down. That is how things go in time.

For the good of the project and the community, I encourage Gargron to do the work to build a foundation with good people on the board and relinquishing control to the foundation while letting him be the tech lead for the codebase. It’s a doable thing!

Best regards,
pnathan


#31

I just don’t think it’s productive to talk about replacing the maintainer with what is functionally a board of directors. The nature of the challenges mastodon faces do not really lend themselves to this, and it’s frankly annoying to see @Gargron 's role trivialized like that. Gargon is the project maintainer.

That being said, I do think you need to work on being more public about your process @Gargron. I get that you want to preserve flexibility to be able to focus on issues that are important to you as they emerge, so maybe there is a better way to convey project status than timelines?

Honestly, I think it would be nice to have a vision statement somewhere. I think the closest I’ve seen is the overview paragraph on the patreon page.

The social focus of the project is a viable decentralized alternative to commercial social media silos that returns the control of the content distribution channels to the people. The technical focus of the project is a good user interface, a clean REST API for 3rd party apps and robust anti-abuse tools.

Which sold me, but I’d also like to see that developed out into a strategy statement and sort of get a better idea of short and mid-term goals, even if they get uprooted to deal with an emergant situation. I think it’s just better that we know the lay of the land, it can help us as a community to manage resources and better understand the decision process on your end.


#32

I agree that the current “one-man show” model is not scaling well and will not be sustainable in the long run. I have seen several developers end up distancing themselves from the project over differences of opinion with @Gargron that could have been handled more diplomatically.

One of the frustrating things about Twitter and Facebook is that they are not beholden to the user base; the users have no say in development, UX, etc. And I can see Mastodon going this way eventually. The more people who join and contribute to Mastodon, the less fair it seems for a single person to have absolute say over decisions.

I would strongly support Mastodon being run by a proper organization, with a board of directors, a code of conduct, a long-term funding strategy, a mission statement, etc.

As a member of social.coop I am obviously a little biased towards a democratic, worker-owned co-op model, but I am interested in everyone else’s ideas!


#33

I do not understand how “a mission statement” may help to solve practical issues we are facing.

I find it very interesting that a one-person show may stir something great on the Internet. Let’s not break that.

I am observing some heavily institutionalized volunteer projects and frankly there is no model that really does work well. (looking at Wikimedia Foundation for example).


#34

Okay so I’m just a user passing by, I haven’t really been involved in Mastodon development one way or an other so I might not know everything.

However, I find quite worrying the fact that Mastodon still depends mostly on the will of one person, whoever that person might be.
Mostly because from what I’ve seen in other projects (which sure were different from this one), you have a problem each time that very person want to quit. And there are plenty of reasons for that, and I highly doubt none will ever come real here. That person might want to move on with another project, and maintaining both could be completely impossible, or they might be unable to maintain it anymore (let’s give a few ones : burn-out, financial problems, mental health issues, etc.). I have seen many people think they could do that forever and one day found themselves unable to do that anymore.

To me, no matter how you put it : this is a bad governance, even if the person if real good at doing it.

Some other issues I find troubling have already been pointed out : the job doesn’t seem to be doable by a single person. Gargon you said yourself that you couldn’t review all the issues on GitHub, and even if there are some that are here twice or more, if some aren’t really issues you can solve, or are baddly put, I don’t see how you can decide which is which. Therefore, you might miss serious issues that should be reviewed (and from the little I’ve seen, there are a big number of issues tagged with a high severity and some have been opened for several month).

Now, and I think this will be my last point : I personally really hate when there’s a way for a “dictatorship” (now I know, you’re not president of a country, this is “just” a project). But still, everything depends on your good will, even this talk on Mastodon’s governance depends on you. Now I’m not saying you aren’t listening anyone (from what I’ve see, this doesn’t look true), however you could still do that if you wanted to, and apart from people stopping to contribute to the project, there would be no way to change that. Now, my personal idea of how things should be managed probably influences what I’m saying here, but I don’t find it ridiculous.

Here’s the little I had to say about this topic.


#35

I totally get this. I think what @Sylvhem is noticing is the result of the way free code communities have tended to grow; organically, not by design. For a small project, or one run by people who really like keeping everything in one place, it’s fine for the Issue tracker to also double as a community forum.

Since Mastodon has this Discourse forum, it would be good to nudge folks towards holding more blue-sky brainstorming type discussions here, to reduce the amount of noice in the dev area. But even if that would be helpful to the Mastodon community, it’s a culture change, it will take time, and trying to enforce it in a bureaucratic way will just alienate people. I think it’s very generous of @Gargron to allow the community to treat his office like an ongoing BarCamp :wink:

The governance issues follow a similar dynamic. When Mastodon began, nobody new if it would get big enough or last long enough to require a formal governance body. Arguably, we still don’t know that.

What I suggest is forming a working group of people who are willing to put some serious hours into organizational admin, and who between them represent a broad cross-section of people involve in Mastodon as devs, instance admins, and end users. Those people could work with the new Community Manager (if there is going to be one) to do two things;

  1. clearly document how things work now in Mastodon. Who does what, and who has what responsibilities and privileges. It’s amazing how many misunderstandings can be cleared up, and dropped balls avoided, just by doing this.

  2. come up with a plan for a community-led governance structure to present to Gargron. One that engages with the reality of who and what the Mastodon network is now, and is likely to be over the next 2-3 years. One that respects the rights of the workers who maintain free code software to be self-managing, and respond creatively to user needs, in the spirit of the Agile Manifesto (not the Agile™ Scrum™ cargo cult).

  3. Seek consensus on which existing foundation (or other free code stewardship body) could potentially be asked to be a legal and financial umbrella for Mastodon until the community is organized enough to create its own (if it even needs one). Examples of orgs that do this for projects include the GNU Project/ FSF, Debian/ Software in the Public Interest, Software Freedom Law Centre, Software Freedom Conservancy, and Apache Foundation.

I really wouldn’t worry about writing a formal constitution, or registering a legal entity, just yet. Having served on the governance group of organizations that have these (and written a constitution for one), I can tell you it’s essential to make sure you’re ready for the administrivia work that maintaining a legal entity requires. There’s a lot of administrational plates to get spinning before you get to that point.


#36

Yes there is, it’s called a fork. Large free code project depend on many contributors; engineers and designers but also documentation writers, bug reporters, community managers, morale upkeepers and all sorts of other undefined roles. When the people controlling a project lose the goodwill of that community, and refuse to compromise, the community can take a copy of the code and create a new project to do things their way.

This happened when the OpenOffice developers walked away after they were acquHired by Oracle, and formed the Document Foundation and LibreOffice. This is a last resort, it creates a bunch of disruption, and extra admin and community regrouping work. But it’s there as a final failsafe that protects free code projects in the (rare) event that benevolent maintainers become unreasonable despots. Because it’s there, most maintainers make the effort to stay in touch with the needs and concerns of their communities, and do their best to be good leaders, not bad bosses.


#37

Since there has not really been any movement or even proper conversation on this topic, I decided to take the advice of Gargron and #ForkOff

For anyone who wants to know what #ForkOff is about, it’s basically focusing om Mastodon Project Governance, but in a fork.

For the most important bit of that thread:

No one can #ForkOff alone, but together we may be able to.

I present to you: The Great Fork-Off Survey of 2018

https://goo.gl/forms/lZb2R1lEGFf6RIGg2

For anyone who’s concerned that forking is a hostile action I got you covered with this thread:

But it can easily be summed up with: Forking is Self-Care


#38

I think there is an important factor to incorporate into this discussion:

We have to identify wishes or demands regarding the network as a whole, the server and the client software. I am afraid that many of suggestions are concerning fediverse as a whole, not just purely Mastodon software (“tootsuite/mastodon” on GitHub). I think that’s a source of many misconceptions regarding alternative software like Pleroma.

So the question is:

  1. What are requirements directed at the federated protocols (OStatus/ActivityPub, the protocol)
  2. What are requirements regarding some specific non-standard extensions (conventions)
  3. What are requirements regarding the client and the user interface

As I have stated on the toot I would like to start documenting the current state of 2, the unofficial extensions which make it really “the Mastodon network”, which is not GNU Social and not even Pleroma.

Finding consensus on protocol and conventions will be difficult. Disagreements here have lead already to instance blocking and the network split may happen which will destroy the biggest value we have: federation

I understand that non-technical users may have trouble identifying if they wish or requirement are part of 1, 2 or 3 and it would be good if more savvy users could help
to categorize that.

There are already labels on the tootsuite’s GitHub like activitypub, ostatus webfinger for protocols. User interface ui has its own big category.


#39

Okay forkers aside, what we basically need now is the thumbs tentatively raised from Gargron to put our heads together on this and come up with some proposals

I imagine there’s a broad range of ideas out there and I’d be happy to volunteer to collate what we here have (and indeed beyond) if people are happy for me to do so


#40

This is drifting off the topic of Mastodon governance, and into the larger top of fediverse governance. There has been some speculative discussion on this here:

Briefly though:

As I have stated on the toot I would like to start documenting the current state of 2, the unofficial extensions which make it really “the Mastodon network”, which is not GNU Social and not even Pleroma.

I would like to see Mastodon (and any forks) fully implementing the ActivityPub spec both the server>server and server>client protocol sets, and documenting anything it wants to do that really can’t be done within the spec as formalized AP extensions. I would like to be able to create a new app, implement the AP spec, and be able to federate with Mastodon instances out-of-the-box without having to reverse engineer any inessential weirdnesses.

There are heaps of people creating new AP-compatible apps, and if AP is successful, there will eventually be hundreds (or thousands!). If every app has to maintain a ticket for debugging federation with every other app, it cannot possibly scale, which defeats the whole purpose of having a common standard. Imagine if every email server or client had to have an open ticket for debugging federation with every other one!