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.
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.
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
Four new FEPs are awaiting editors’ approval. Is there anything that prevents them from being accepted into the FEP repo?
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)
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.
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
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
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".
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.
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)
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.