Sure, I don’t have any objections to that. If anyone else does, feel free to raise an objection.
Off the top of my head, the feps/fep-xxxx.md links will likely be present in old threads here on Socialhub, as well as if anyone linked to them externally anywhere else. I assume the assets would have significantly less links, though.
Yes, feps folder contains documents with redirection links, so it shouldn’t be removed (for a couple of months at least). Removing assets is probably okay.
And while we are on this topic, @helge could you merge this pull request? #115 - Fix redirects for some FEPs - fep - Codeberg.org
We can change the links to new permalinks if that’s required. I have documented how to do it somewhere in the howto I think.
Welcome as FEP Editor, @silverpill 
Thank you @aschrijver !
I’ve merged the PR with fixes. Everything seems to be working, CI is running etc etc.
I also think we should merge #117 - Automate things - fep - Codeberg.org as it significantly improves the editor’s workflow. It would be nice to get approvals from other FEP editors.
New PR that changes the description of authors metadata field in FEP-a4ed: #138 - Specify how "authors" metadata field should be used - fep - Codeberg.org.
I’m curious about this statement. Can someone clarify the situation?
In the meantime, I added a way to automatically link mentions of FEPs in the conversation to link to the seemingly broken repository… So… fep-a4ed would link to https://codeberg.org/fediverse/fep/src/branch/main/feps/fep-a4ed.md (which is configurable, of course).
I think I was referring to that the changed folder structure forced everybody who has work in progress to perform maintenance.
This should not happen again once #134 - FEP repository governance - fediverse/fep - Codeberg.org is implemented.
@fep.hosts Please provide your feedback on #138 - Specify how "authors" metadata field should be used - fep - Codeberg.org. The pull request contains changes to FEP-a4ed
Many MarkDown applications use YAML for frontmatter. The current FEP frontmatter is technically YAML-compatible, but if some fields like authors were YAML lists (of name/value objects?), it would be easier to process the metadata. Currently, one needs to parse the comma-separated string into a list of name/email pairs.
CommonMark doesn’t have an official syntax for footnotes, but there are widely-used extensions that support it ([^my-footnote]). I think it would be useful to convert footnotes to use the footnote extension syntax so it’s compatible with a wider range of MarkDown-related tooling.
As an outsider looking in, the currently described goals and scope of the FEP process seem vague and somewhat self-contradictory to me. Based on comments I see in other discussion, I think I might not be the only one. I’d like to see a clearer description of the goals and scope (maybe separated into goals/scope for different kinds of FEPs). I’d propose something, but I’m not clear about which direction the editors would like to take this, or if they are fine with the status quo.
(I can’t submit this as a separate reply…)
I’d like to see some better categorization of FEPS (e.g., “documentation”, “implementation report”, “idea”, “humor”, “social/cultural”, “best practice”, “specification”, etc.). I’m not claiming these are the best set of categories, but I think some categorization would help developers understand the intent of an FEP and guide them to the information they need for their objectives at the moment.
(Separate issue…)
The FEPs link to the Codeberg issues for discussion. My understanding is that SocialHub is recommended for discussion. Should these discussionsTo links be changed to link to SocialHub or maybe the metadata field changed to issues. Even with the latter, it’s not clear which discussions should be had in Codeberg issues versus SocialHub.
+1 (if Codeberg supports YAML lists in front matter)
Does Codeberg support this syntax? Or maybe there are plans to support it?
Personally I’m fine with the status quo, but I’m not against changes to this section either – as long as the core principles of the FEP process like neutrality and inclusiveness are kept in place.
This places an additional burden on FEP editors, and I don’t see much benefit in categorizing FEPs.
Discussions can happen anywhere (not necessarily on SocialHub), or there might be multiple related topics. Tracking issue is used to collect links to various discussions.
Whether discussion in tracking issues should be allowed or not is an open question. I’m in favor of allowing it. Some people are not comfortable with using SocialHub, or may not want to create yet another account.
I don’t know about Codeberg, but ForgeJo supports it. I know Codeberg is based on or somehow related to ForgeJo, but I don’t know if it is using the latest ForgeJo code. I tried it in my self-hosted ForgeJo instance and it works fine (version 1.20.2, but I don’t know when they added these features).
(Re: footnotes)
My ForgeJo instance supports it (automatically links ref to footnote, which I’m not seeing in the current content on Codeberg).
I described one benefit that I see already in my original comment. Another potential benefit is that the process might differ based on the category of an FEP. Documentation for the MeowPub implementation (possibly intended to be humorous) or an FEP that describes Fediverse social or cultural issues might not need to “finalized” or approved. Categorized well, a developer interested in interop guidance with existing Fedi apps, for example, would know those are not relevant.
I don’t want to place an additional burden on the FEP editors. I’m not sure why, given a set of candidate categories, an author can do the categorization with a pre-merge review by the editors. I think the point about not seeing much benefit is probably the relevant one in this case.
OK, thanks. It wasn’t clear to me that it was still an open issue. If so, I suppose the discussionsTo link to the related Codeberg issue is appropriate. Maybe that’s where my current suggestions should have been recorded?
By the way, I think the FEP editors are doing a great job. I hope my suggestions for process improvement don’t give the impression that I think otherwise.
I suggest they would voice their concerns themselves and explain why. The FEP process was born here and we’re trying to reinforce this community, not split it again. One thing that is certain is that the integration of Codeberg issues and the FEPs with Discourse could be better. That may be one useful task to tackle, along with the upcoming portal.
+1 to the need for categorization. If that increases the burden on maintainers it may be more an indicator to carefully consider the role and scope of the FEP Process. Should it handle everything but the kitchen sink?
On FediDevs chat I proposed we create a Milestone with open issues related to FEP Process improvements to give priority to. @stevebate you might shoot an issue about categorization.
Where’s the right place to create the issue?
The FEP repo: https://codeberg.org/fediverse/fep/issues
Just to make my positions clear:
I tried to change it in the FEP template (preview, issue). Looks better, in my opinion. If other editors are not against this change, I can update authors field in all FEPs.
Do you imagine that authors will use footnotes in “References” section of their proposals? Perhaps you can demonstrate how this will work by changing some existing FEP (for example FEP-a4ed)?
You’re right, categories might be useful. What I wanted to say is that an additional maintenance burden is probably not worth it, even if categories are assigned by authors themselves. I’ll comment on that in the issue.