FEP-a4ed: The Fediverse Enhancement Proposal Process

I’d like to keep FEP lightweight (on the human factor). I am not interested in being part of a process with more human involvement.

On another note: I’d like a process with less human involvement, i.e. automatic tests.

It is about making the FEP “fit for purpose”. E.g. with a further structuring of the 3-stage Standards Process and providing guidelines for developing extensions, FEP editor work may be lighter by allowing anyone to self-register and maintain arbitrary extensions (in an NPM-like registry), but OTOH require a bit more work on relevant stuff that needs to be put on a standards track towards broader adoption (maybe up to W3C SocialCG level). In other words less FEP’s than now, but more formal process.

My fear is that the current FEP process will lead to a flat unmaintainable list of unrememberable ID’s that people hate to consult and will therefore share and cross-reference less etc. Every FEP added is extra work refactoring later.

Note that another FEP Process improvement related issue was started by @nutomic.
Cross-referencing to:

A possible solution boils down to Compliance Profiles once more, where:

:point_right:  Good implementations tell you what FEP’s and other extensions they support.

(PS. I just checked if the XEP has something like this, and then found Service Discovery to be similar to Compliance Profiles and able to deliver fine-grained Features to discover.)

Another downside of hash-IDs is a constantly increasing probability of collisions (although we can switch to longer IDs when this starts to happen). I’ve opened an issue about switching to sequential IDs: #196 - Consider switching to sequential IDs - fep - Codeberg.org

My impression is that almost everyone involved enjoys the FEP in the current form. If there’s a need for something more complicated, perhaps it should be addressed by starting a separate process?

Maybe it is a good idea to design an improved FEP process in parallel, before switching to it. But there should be buy-in to make the switch IF the new process brings clear improvements or it is not worthwhile.

When you say “everyone involved enjoys the FEP in its current form”, I doubt that. Maybe people involved enjoy slowly improving the FEP on the many points where improvements can be made. But that is different.

Also “everyone involved” (a handful of people) is a much smaller group than the audience of everyone who should be involved. Position the process as that 2nd-stage in the Standards Process within the AS/AP Fediverse is still way off. New fedi devs don’t know about the FEP, and I’ve heard quite a few devs musing about writing a FEP but not doing it. Apparently the barrier was still too high and it wasn’t deemed “worth the effort”.

Maybe instead of a parallel track we should give the FEP an improvement to its own development process. I mentioned this before. We might version the current process v0.1 and work towards a v1.0 with a roadmap, have a project + kanban on codeberg and prioritised backlog of issues to tackle, define milestones, etc.

I’ve added another pull request to simplify the readme creation process:

Thanks @silverpill for noticing that I edited README.md again without noticing my warning of it being automatically generated.

Edit see: #199 - Improve creation of README.md - fep - Codeberg.org

I now modified the setup:

  • On a pull request only test_feps is run. This means it is checked that all FEPs are correctly formatted.
  • On the main branch, also test_readme is run. This means it is verified that README.md is the file generated by scripts/create_readme.py.
    • As a consequence, the initial merge of a new FEP will result in red tests
2 Likes

By everyone involved I mean FEP authors and readers. I haven’t heard many complaints from people who use the FEP process.

That’s understandable - writing a FEP requires a lot of effort. The submission is the easy part (some people might be discouraged by the requirement to register Codeberg and SocialHub accounts, but I don’t think we should move everything to Github because of that).

I agree that writing a FEP requires effort, and it should be simplified. I think an ideal world would allow people to use their Fediverse account to just submit a FEP by pasting something into a text box. Maybe into something like a predraft stage called “Sketch”. The only step required should be filing out the text box.

Then I could comment on the post Hrefna (DHC): "@letsbekind2@eightpoint.app Two types. One is…" - Hachyderm.io about canaries in blocklists is turned into a FEP, “You should turn this into a FEP Sketch”. The advantage would be that instead of requiring the person to spend a weekend on writing the FEP, only half an hour is required.

This is very much in line of my vision of FEP containing knowledge, and encouraging people to contribute.

3 Likes

I really like the tools you folks have added to the repo already. Kudos!

1 Like

I opened a PR to address this: #220 - FEP-a4ed: Updating proposals - fediverse/fep - Codeberg.org

Opened another PR: #229 - Fix formatting of references - fediverse/fep - Codeberg.org

@fep.hosts Please review (and the previous one too).

2 Likes

Done. Thanks for the reminder.

1 Like

#229 - Fix formatting of references - fediverse/fep - Codeberg.org has been merged.

#220 - FEP-a4ed: Updating proposals - fediverse/fep - Codeberg.org is approaching the end of review period, but has only one approval.

@fep.hosts #220 - FEP-a4ed: Updating proposals - fediverse/fep - Codeberg.org is still waiting for your approval (or a rejection).

To be honest it looks like FEP process needs more facilitators. Any volunteers?

1 Like

A post was merged into an existing topic: Looking for volunteer FEP process facilitators

@fep.hosts Please review proposed changes to FEP-a4ed: