i think keeping the filename as fep-xxxx.md isn’t a big problem, it should be possible in something like hugo to set a frontmatter.slug to the identifier xxxx, then configure the permalink output/generation to be /fep/:slug – consequently, i think this consideration can be closed
re: the old directory, we can add a README.md explaining that it is deprecated; whether the directory should be removed is a question that can be revisited later if it ever comes up. so this consideration can probably also be closed.
so i think i will edit the repo’s README.md to reflect the new instructions of creating a subfolder rather than just copying the file. i will also verify that the permalink+slug strategy works for generating the HTML documents at the right URIs.
As the discussion on how to format pages, e.g. bikeshed vs hugo, depends on it. I’m not so sure. As I stated above. I don’t know where we — the FEP community — want to steer FEP to be positioned. Without knowing the answer to this question is to hard to determine if this PR is a step in the right direction.
For example: If our target audience was python developers. I would veto these changes. It would be more sensible to use restructured text and sphinx to format the FEPs. Automatic building can then be done using readthedocs. I’m not even sure this would be a bad proposal for the broader community. Of course, rust fans might suggest https://docs.rs/ and so on …
i’m not sure static site generation really depends on this PR, although the PR makes it easier and is rather agnostic towards the issue. but i’m also not sure i understand what restructuredtext has to do with this. a move away from markdown sounds like a much more significant change, and i don’t really see the benefit of doing that. whereas the benefit of “one folder per FEP” is clear in that you can bundle additional assets or sidecars with the FEP, and this is something that makes bundling context documents easier for example.
These changes create overhead. This overhead can only be justified by benefits. As the author of two thirds of the FEPs with assets (which is what the PR should help), I don’t currently see the benefit.
can you clarify your objections to this PR? personally, i would say that this PR reduces overhead, since it makes FEPs self-contained within their own folder. and surely there will be more than two or three FEPs with assets in the future… especially when FEPs start adding context documents for their extension terms.
The objection is overhead. Having a file in a directory is more complicated than just having a file. If on creating a FEP, I have to create a directory and a file, instead of a file, that’s overhead. What is complicated about this?
Anyway, this discussion is now considered unnecessary overhead by me, and I’m out.
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
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:
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).
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)
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.