FEP-a4ed: The Fediverse Enhancement Proposal Process

It’s understandable that mostly people want to discuss the new design instead of why a new design needs to be adopted. @helge comes closest here to what I was getting at about valid problems by stating:

As someone who has worked with assets, I can say: @trwnh’s structure will creating a FEP with assets a little easier. At least it is clearer where to place them. It’s all in one folder instead of multiple ones.

Which alludes to it being a problem not knowing where to place assets. @a has submitted the PR and @aschrijver approved it so from that I’m going to say that a majority here think it’s a valid problem.

For that reason, I’m merging this PR now and we can move on.

Why? Clearly there’s no consensus regarding naming. Also, I just noticed that redirect links are broken:

fep/fep-e232.md at main - fep - Codeberg.org redirects to directory listing, not an actual document.

In my opinion, this change should be reverted immediately.

So we can continue to move toward a better state. If you think there’s a problem with what was just merged, please create issues and PRs. We should discuss and merge our way out of this, rather than revert.

The way out of this is revert and have a proper discussion. There was a suggestion to use README.md, which wasn’t addressed in the PR. I didn’t even have a chance to respond to last comment and properly review the changes. Moreover, earlier I said that we should be careful with this change:

And now somehow I’m supposed to fix this? Also it is not clear why this PR was merged after 3 days despite the objections, but my FEP submission was ignored, and now stuck in limbo because the directory structure has changed and may change again.

My conclusion is that FEP process is unreliable. If this issue will not be resolved, I will rather publish my proposals elsewhere.

I understand your objection but the discussion on the PR itself was adding to an idea that consensus needs to be found on changes before they can be made. The only part of FEP process that requires anything close to consensus is on which problems we should solve. The best read I could get from the various posts was that this was a valid problem.

After that determination, merging even less-than ideal solutions is preferred over protracted debate. This PR wasn’t WIP so it was eligible for merge.

From here, if anyone sees a problem let them create an issue in the tracker or on SH so we can discuss and repeat this cycle often, each time getting closer to what works for the most people. For more information see C4 which I’m informally following to manage this repo. This is a volunteer best-effort by everyone including me.

As for your submission, ignoring it wasn’t the intention. I was just processing what was actionable as I saw it. I hope you’ll reopen it and continue to contribute as interested.

1 Like

Since no objections have been made, I think it’s time to move forward.

New directory layout

I don’t disagree with the proposed layout. The only thing that appears to be broken is redirections, and I’m going to fix them at least for my own proposals. Another, relatively minor issue, is the new slug metadata field, which is not documented in FEP-a4ed. Is it really needed? There should be a way to make static site generator generate nice URLs without adding clutter to FEP documents. @trwnh

New FEPs

Four new FEPs are awaiting editors’ approval. Is there anything that prevents them from being accepted into the FEP repo?

New editors

@helge, is it true that you’re now a FEP editor? I fully support this move. Shouldn’t EDITORS.md file reflect this change?

FEP governance

I don’t think this is a good practice. FEP process is very important part of the Fediverse, and it should be predictable. Here’s what I propose:

  1. Significant changes to FEP process should be reviewed by the majority of editors. The length of the review period should be specified in FEP-a4ed (e.g. one week since last commit).
  2. Proposals should not be changed or moved without author’s consent.

i think you could programmatically extract the slug from the filename or folder name, and then inject it into the frontmatter as part of the same script, but it’s something that can be avoided by simply prefilling it. i have no strong opinions on this though; it’s purely an enabler that reduces effort.

this should be easier after the new directory layout. permission to edit a specific FEP’s subfolder is now very clearly in the purview of that specific FEP’s editor(s).

this does concern me, as there is now discussion happening on those PRs and not in a tracking issue or a forum thread (which are easier to keep up with, as opposed to having to track down potentially multiple PRs for the comments on each)

1 Like

I’ll move a discussion from Continuing the DoOcracy - #21 by helge to here, as it belongs to this topic.

To put it bluntly: Merging pull requests that change the directory structure without a multi week warning is not ok. Everybody who had a draft FEP probably got fucked. I am unwilling to have something such as features in a repo that changes like that.

The homework was not done before changing the directory structure, so it needs to be done now. As I’m still annoyed at the entire thing, I don’t see myself being the one doing the homework.

I’m frankly in favor of freezing FEP until the homework is done. This will take time, as I’m still too annoyed at the entire thing to write cool headed stuff.

1 Like

Hmm, I approved the change of directory structure PR by @trwnh but however overlooked the broken links. So apologies for that. It may be an improvement if we have as rule multiple PR approvements for changes to the FEP process itself. Other than that, if there’s no issue reported about the breakage, then such bug can go unnoticed for a long time, and be angry is no use.

I hope to spend some time tomorrow. FEP editors group is volunteers, and apparently time is an issue. So we may need more editors, and certainly be careful about adding more (time-consuming) formality. Even though a more formal FEP process may be well in order.

re: various comments across the two threads: i’m still confused why linking to the directory instead of the markdown document is considered “broken”, as you can still get to the markdown document with one click. “broken” to me implies a 404. i don’t think it really matters. likewise, i remain confused what the “uncertainty” is regarding the folder structure. you make a folder, and you get ownership of that folder, and all your stuff goes in that one folder. i might not like how it was merged, but it’s hard to argue that it was bad to merge.

I took over this notion from @helge’s post and the first time I became aware of issues or discontent. But until (hopefully) tomorrow I don’t have time to look deeper into it. If there’s another confusion or disagreement in opinions how things should be done, then it may be better to bring clarity first in this thread.

I just scanned this thread, I had it muted because it annoyed me (it still does).

This entire slug discussion reminds me: What is the plan?

A lot of stuff discussed here can be easily be scripted away. It literally take less time to code up, than reading this thread does. However, I have no idea where the ship FEP is being steered right now. So I’m unsure what should be done.


Creating a new FEP has become more complicated enough now:

4. Copy the FEP template ([fep-0000-template.md](./fep-0000-template.md)) to the [feps/](feps/) folder and change the filename to fep-abcd.mdwhereabcd is the identifier computed in step 2.

became the monstrosity

  1. Create a subdirectory of fep/(fep/) using the identifier you just computed. Copy the FEP template (fep-xxxx-template.md) to this subdirectory and change the filename appropriately. Use the identifer as the “slug” when filling out the frontmatter. For example, if your computed identifier was abcd, then your file would be located at fep/abcd/fep-abcd.md and your frontmatter would include slug: "abcd".

That should be like three points

  1. Create a subdirectory of fep/(fep/) using the identifier you just computed.
  2. Copy the FEP template (fep-xxxx-template.md) to this subdirectory and change the filename appropriately.
  3. Use the identifer as the “slug” when filling out the frontmatter. For example, if your computed identifier was abcd, then your file would be located at fep/abcd/fep-abcd.md and your frontmatter would include slug: "abcd".

We probably need to provide a FEP create script now. Or is there some hidden goal in making creating FEPs harder? I’m confused of the goals here.

1 Like

The goals are what we want to make together, and what happens depends on who can dedicate time and effort to make it. There’s nothing hidden. Yes, the coordination can be frustrating, and yes long threads get hard to follow.

Readers might be not familiar with Codeberg UI or the FEP process. It is not obvious that one should click on an item with esoteric name like fep-a4ed.md. It just feels like the site is broken.

There were different opinions about optimal structure. Are we going to use fep-****.md or README.md file name? If we decide to switch to README.md, that would be another breaking change. Hence the uncertainty.

(I’m not suggesting to use README.md; I was initially in favor of this option but changed my mind)

This only works if people don’t create massive amounts of work for other people.

Anyway, Codeberg CI is still troubled, so automating away the necessary FEP stuff (various checks, creating tickets, opening topics on SocialHub, etc…) will have to wait.

Thanks @helge, I agree. I didn’t have time yesterday to read up on things, and very busy coming days. I hope other FEP editors have time to spare. As said I think more candidates for FEP editor are welcome. Maybe @silverpill and @trwnh are willing?

One way to improve our process is to have actionable issues on the tracker, that point to background material here on the forum. That way we don’t have to comb overly long and various threads.

1 Like

I’m currently trying to automate away parts of the editorial process, e.g.

  • Basic template checks
  • Updating the main table
  • Creating the tracking issue

This will hopefully reduce the workload on FEP editors.

Unfortunately, it’s not as easy as hoped, e.g. codeberg-ci is currently having issues.


Can somebody with admin privileges on the FEP repository enable it on ci.codeberg.org? I don’t have enough permissions to do so.

1 Like