The Process/Platform Isn't "Working"

While I haven’t really been an active participant in discussions on this medium, and probably not up-to-speed on all the past decision-making, history, and processes—it feels like something isn’t working.

It feels like it’s a specific selection of reoccurring participants, while most other developers have just tuned SocialHub out entirely. Generally I see complaints that it’s hard to keep up with relevant topics, new relevant FEPs, or the inability to have meaningful influence.

Platform
I can’t really pin down all of the complaints I have, as I don’t know if I just have adjustment difficulties with using Discourse (which seems more free-form) versus dealing with a conventional forum-section hierarchy, or other specific UX/UI design patterns. For example, with just structure/categorization for something process-oriented, I’d normally visualize a hierarchy like (the categorization, not the web design):

Also, some parts of Discourse’s design feels like it’s trying to overly de-clutter the interface (compared to phpBB/vB/etc) and squeeze down how much content is shown on the screen at a time, to where it’s a little constricting. For example, on traditional forums, you’d usually have a mini-profile next to each post, with a few specific profile fields shown. In Discourse, you have to click through each profile, to gain a little context about the poster; it was only a week or two ago that I even realized there was a dev from Mastodon or Friendica fairly active on here. A lot of other users I still have zero idea what their interest/stake in the forum is (but that’s because they haven’t filled anything out).

Process
I’m assuming the FEP process was motivated more to get existing projects to open up and document any extensions they’ve made in their project, so that it’s easier for others to interoperate. On this platform, it feels like kind of a one-sided relationship, where it’s about someone pushing out a FEP, and expecting others to follow. It doesn’t feel like a broader collaborative effort, more just a system of calling for feedback and edits (or just documenting the behavior in their software only), rather than something that starting with a discussion, and trying to piece together what other projects want to see, and then working it into a FEP.

Tangentially: We have one system for quote-posts in production that never had a FEP, we have another proposal as a published and implemented FEP, and we supposedly have another vendor privately working on their own possibly-incompatible proposal that is intended to be dropped on everyone as their own FEP. I understand that nothing about the FEP process could probably fix this, but part of it feels like there’s still a problem with finding a good communication/collaboration medium or structure between projects, that vendors just choose to not go through the hassle of collaborative discussions.

Another pattern is that it feels like people just want to write up their own FEPs, without even having to implement it themselves, and that it’s merely just encouraged for an implementation to exist. In my worldview, it should usually be a requirement to have at least two independent implementations being able to implement a FEP (if the FEP calls for anything behavioral in software), from the specification alone, before it can be recognized as a stable standard. Just one person implementing their own idea in their own software isn’t enough, because it doesn’t ‘field test’ the specificity of the FEP.

Within the same day as an important security update pushed out in Mastodon, Misskey, and other projects: someone’s already pushing out a FEP to steer validation/verification criteria for implementors, before there’s been a more careful discussion. There are a lot of avenues to addressing recently spotlighted problems, but pushing one suddenly-revealed option feels very haphazard.

Nonetheless, these are my passive observations I’ve had in orbiting this forum for several months or so (on-and-off) that I’m sure I have some misconceptions, or of there being previous important posts I’ve overlooked, etc. There are a few things I’d like to get in motion with my own server implementation, but it doesn’t feel right to just shove out a FEP right away, as I’d rather check with what makes sense first. But also, there’s only a narrow selection of developers of projects active here, that I don’t even know if anything proposed/formulated here will get sufficient feedback to make a FEP that gains tangible adoption.

5 Likes

I think @silverpill had something like this in mind when they were making FEP-e232, although I don’t think its a requirement. I would also think that it might not be a good idea, since an implementation on the careful side might only want to implement a FEP that is already finalized, creating a chicken-and-egg situation.

Regarding the issue of FEPs just “trundling along” for the most part is I think an issue that some of the bigger implementations (especially the elephant in the room) don’t seem to care too much for interoperability, let alone FEPs, if they can get away with it. I think the elephant in the room in particular might be quite happy to be the one to mostly decide how the W3C recommendation is to be interpreted and the unspecified but necessary parts are to be filled.

Having “only” a few other smaller implementations implement a FEP is kind of cool because of the collaboration, but on the other hand also frustrating if it does not get any wider adoption.

3 Likes

It is good to have two independent implementations when a protocol extension is being proposed, but some FEPs are not related to the federation protocol, see FEP-37f2 for example. Such proposals can be excluded from the process, but personally I don’t want to do that.
One possible solution is categorization. I’m fine with this idea, but I think categories should be assigned by authors, not editors. Someone just needs to submit a pull request with a change to FEP-a4ed.

elephant in the room

Actually, there are at least 3 FEPs from Mastodon developers!

FEP authors may choose to not incorporate feedback from other implementers, but this shouldn’t be a big problem because it is very easy to create a competing FEP (and this is where FEP process has big advantage over anything consensus-driven).

I don’t think it should be too burdensome for two exploratory implementations to exist as a prerequisite to something like FINAL status (or perhaps some new label after that). It generally encourages the author to have some actual stake in it, by at least adding it to their implementation (or modding it into someone else’s) to cover as 1 out of the 2 required implementations.

And I don’t think implementors are going to solely evaluate something by it’s status label, without checking who currently adopts it, which usually carries more weight than the label.

Hence I had worded to the tune of “if the FEP calls for any behavioral [change] in software” as a condition to that requisite, or perhaps I could reword it differently.

I’ve opened a pull request that defines two categories for FEPs: informational documents and implementation proposals. #291 - WIP: FEP-a4ed: Categories - fediverse/fep - Codeberg.org

With this system in place we can later introduce different finalization requirements for different categories of proposals.

2 Likes

Cooperation is a hard process to solve in a social world that pushes competition as “common sense” this non consensed fep process is the #geekproblem trying to mediate this hard process.

To actually, honestly, make this work, you would need to nurture a wider social change/challenge community. This we have not done over the last few years, instead we have been actively (with nasty “common sense” behaver) #blocking this obviously hard and needed process.

It’s not obvious at this stage of fast #mainstreaming of our openweb tech that anything can be done now? Ideas please (and please, I should not need to say this, in general don’t be a prat in replies, thanks)

A path

Issue within the fediverse community regarding the handling of problematic behavior or interactions on the platform. A breakdown of the key points:

  1. Problem with Blocking: That simply blocking users or instances (such as the #dotcons) is not an effective long-term solution to fostering a healthy and diverse community within the Fediverse. Blocking is “putting your head in the sand,” implying that ignoring or isolating problematic elements doesn’t resolve underlying issues.
  • Advocating for Openness: Emphasizes that the Fediverse should remain true to its principles of openness (#4opens), which allow anyone, including controversial entities like the #dotcons, to participate. This openness is a positive aspect of the openweb.
  • Building a Healthy Culture: Rather than relying on blocking, we need to advocate for actively building a healthy culture within the Fediverse. This involves nurturing diversity of tools and fostering a community where constructive engagement and dialogue can thrive.
  • Need for Engagement and Solutions: The importance of proactive engagement and problem-solving. we need to warn against passivity (“hiding in a cave”) and encourages efforts to address challenges head-on to create a stronger and more resilient ecosystem.

Overall, a call for constructive action within the Fediverse community, moving beyond simple blocking measures and instead focusing on building a robust and inclusive platform that aligns with its core values of openness and diversity. With an emphasis on proactive engagement, collective responsibility, and continuous improvement to create a healthier online and offline environment.

1 Like

This discussion is reminding me of a few I’ve had in the past, so I’ll give my two cents here. Cooperation amongst a distributed group of individuals, groups and organisations is inherently tricky. Setting up and facilitating Pavilion (a distributed workers cooperative) and various other online cooperative efforts in the last eight years has given me the odd grey hair.

There is no silver bullet to this. Individual efforts are needed. Collective efforts with consensus are also needed. On balance I think ActivityPub development and standards have probably skewed more in favour of individual efforts, with the FEP process being one reflection of this. I broadly agree with @hamishcampbell’s calls for openness, supportiveness and engagement.

I would suggest that the way to think about this, the way to approach this mentally, is one of “flexible constructiveness”. Efforts like FEP, discussion on this forum, discussions elsewhere, SWICG, and the new Forums and Threaded Discussion Taskforce we just set up, and many other efforts, have to be thought of as complimentary forces rather than alternatives, or in tension with each other. Some things will work in some situations. Others will work in other situations. You have to be ready to adapt to be truly constructive. Searching for the best way to cooperate in these efforts (online and distributed), is an endless quest (I’ve been on a few times). There is no best way.

The biggest problems for collective action are not ideology, bad intent, or even commercial interests (though they can all be factors too). The biggest problems are time and focus. People are busy trying to live and provide for themselves and those they care about. They only have so much time to dedicate to things like this. The privilege of time, and who has it, to engage in collective online efforts is an interesting discussion (perhaps a separate one). This is why it is sometimes necessary to have meetings, so someone can schedule in time to understand what’s actually going on. For the same reasons, it’s also necessary to have a robust async collaboration. Sometimes people can’t, or don’t want to, come to a meeting. Both are needed.

In summary, I would endorse:

  • the efforts to improve the FEP process;
  • the calls for a supportive and inclusive culture;

and call for a pluralistic approach to both:

  • methods of collaboration and norm-setting (i.e. FEP, SWICG etc); and
  • the “actors” involved in this collective effort.
4 Likes