Conversation

Notices

1. Embed this notice
   Aurynn Shaw (aurynn@cloudisland.nz)'s status on Thursday, 08-Sep-2022 05:55:24 JST Aurynn Shaw

   I think one of the things that annoys me most about fedi is that the major software for fedi is handled by a DFL that makes unilateral decisions to support and improve his centralisation of the fediverse.

   Mastodon desperately needs a steering committee and other organisational structures LIKE EVERY OTHER MAJOR WEB THING

   but we don't have that

   because DFL

   • Embed this notice
     ilja (ilja@ilja.space)'s status on Thursday, 08-Sep-2022 05:55:12 JST ilja

     in reply to

     • Dr. Quadragon ❌
     @drq @aurynn Committee sounds pretty formal to me. Pleroma never had that. What pleroma missed in the last couple of years imo was scrutiny of code quality (luckily this has been changing since february). For direction, pleroma does want to be flexible, so yeah, that kinda invites that it can go in all sorts of ways. But that's not because of a committee, afaict that was basically lain's vision from the start.
     Hélène likes this.
   • Embed this notice
     Dr. Quadragon ❌ (drq@mastodon.ml)'s status on Thursday, 08-Sep-2022 05:55:14 JST Dr. Quadragon ❌

     in reply to

     @aurynn
     Meanwhile Pleroma is literally going to Hell because of lack of direction because it was designed by a commitee each member of which has left because they have lost interest.

     Cc @a1ba

   • Embed this notice
     ilja (ilja@ilja.space)'s status on Thursday, 08-Sep-2022 07:13:17 JST ilja

     in reply to

     • Dr. Quadragon ❌
     @aurynn @drq Sure! By the OP, I assume about the way pleroma is/was ran?
     
     Note that I only started to follow the project in 2018 and only got more involved about a year ago. So some things may be somewhat one sided.
     
     Basically lain started pleroma and other people started to contribute and work together. I don't know how it exactly evolved to this, but eventually you had some people working on pleroma based on some unwritten rules. Basically, if you wanted something in pleroma, you could make an issue or MR. In case of an issue, maybe someone would take it up. In case of an MR, people would review it. If a maintainer considered it good to merge, they approved it, if a second maintainer also agrees, they merge it. These were unwritten rules, so there are exceptions (mostly for smaller changes), but in general this worked.
     There were some frictions from time to time however, because sometimes things would happen that someone disagreed with, but things never really got discussed. I don't have examples of this, this is based on what I've been told later.
     Eventually these frictions got worse, remained undiscussed and ignored, and people started to leave. By this time there were payed devs, so development continued and the problems kept being ignored. Eventually the money ran out and it became clear that most people had either left or gotten burned out. Meanwhile pleroma had turned from a reputation of being a solid lightweight codebase, to being a buggy software no lighter than most other microblogging fedi software out there.
     Some people still wanted to work on pleroma, but it became clear there were two different (and incompatible) expectations. On the one hand you had people who wanted to work in a more consensus based way. On the other hand you had people who just wanted to push stuff as long as lain didn't complain.
     Eventually most of the people who wanted a more consensus based way of working left and started working on a fork. Two people still wanted to mend things between pleroma and the people who were now working on the fork, including lain who said they basically want the same thing.
     Talks happened and lain made it clear that they want a consensus way of decision making and always wanted that. It was also made clear that other maintainers have both the power and the permission to act when they see things going in a way they think is wrong. Some people returned to pleroma and the fork died out. This was around new year.
     By now there are people working on pleroma again and some things have been written down so expectations are more clear.
     Pleroma wants to be flexible, so there's no real direction other than what people contribute. Code quality needs to be acceptable, and you have to realise that your changes may affect other people and resolve issues if they arise, but there's no real "end" vision of what pleroma, as a software, must be outside of some generic goals.
     
     Personally I don't consider the people working on it now to be a committee. When someone says committee, I expect elected members, voting, big meetings where decisions are made... Pleroma doesn't have any of that. But I also don't think you can call it a bdfl run project. It's really just a bunch of people who decided they want to work on this project together in a way they can enjoy. At least that's how I see it.
     Hélène likes this.
   • Embed this notice
     Aurynn Shaw (aurynn@cloudisland.nz)'s status on Thursday, 08-Sep-2022 07:13:19 JST Aurynn Shaw

     in reply to

     • ilja
     • Dr. Quadragon ❌

     @ilja @drq Could you explain more on that please?