FEP-a4ed: The Fediverse Enhancement Proposal Process

Again, all in favor, also for the static site creation.

During the transitional period, existing FEP documents can be replaced with a text This document has been moved to <link to a new location>. This would be better than showing 404 page.

:+1:

I also have a rough plan to add tests for fep-2e40. When redoing the folder structure, please keep in mind that a place to have tests and possibly run them from the ci might something we want in the near future.

I tried putting a test case together to serve as an example what this will look like. I’m not 100% happy with the entire thing, but hopefully it will give the right idea on what might be required…

1 Like

Before we restructure, it would good to prove out the problem it would solve.

@trwnh Can you expand on this statement? Does anyone else have thoughts on validity of the current layout being problematic?

yes, this is planned to be supported as well.

  • generate static html from markdown
  • validate context files
  • compile “common” terms into a top-level context
  • create a versioned context whenever a new term is added

i think it is a good idea to practice “asset colocation” and keep FEP-specific files stored within the FEP-specific directory. what’s “confusing” is that we have essentially three current paths that FEP submitters have to be aware of:

  • feps/fep-xxxx.md
  • feps/assets/fep-xxxx/filename.ext
  • contexts/fep-xxxx/context.jsonld (pending 2e40 or 9606)

there is additionally an issue of unclear editing authority. better to avoid write conflicts and just give each FEP editor an FEP-specific directory.

EDIT: FEP-9606 PR has been submitted

1 Like

5 posts were split to a new topic: Auto-assign FEP first topic post to @system user?

I think the proposed layout is indeed better than the current one. But this transition might do more harm than good if not performed carefully.
For new proposals, authors can start using the new layout right away. For existing proposals, redirection pages should be created, as I suggested in a previous post (and ideally FEP authors should be given a chance to move their files themselves).

I would rather opt for the original PURL used across RFCs, which has become an Internet Archive project at https://purl.archive.org. The resulting URLs would be purl.org/fep/xxxx instead.

is there any particular reason you prefer purl.org over w3id.org?

Yes, it’s historical and now supported by a non-profit we all love and trust—we all? :wink:

When I decided to use w3id.org, I looked at purl and it didn’t allow to configure content negotiation (at least as far as I could tell). As content negotiation is necessary for nice json-ld contexts, I don’t consider purl an option.

3 Likes

That’s good feedback to send to the Internet Archive.

This is not legally possible in many jurisdictions. The ability to “palce something in the public domain” mainly is an US American thing.

1 Like

This is why the CC0 was chosen:

CC0 helps solve this problem by giving creators a way to waive all their copyright and related rights in their works to the fullest extent allowed by law. CC0 is a universal instrument that is not adapted to the laws of any particular legal jurisdiction, similar to many open source software licenses. And while no tool, not even CC0, can guarantee a complete relinquishment of all copyright and database rights in every jurisdiction, we believe it provides the best and most complete alternative for contributing a work to the public domain given the many complex and diverse copyright and database systems around the world.

2 Likes

Ah, I overlooked that clarification. CC0 of course fixes that.

1 Like

are there any objections to this? i think i’m just going to do it as a PR

to clarify, this is the current plan:

migrate feps/ to fep/xxxx

  • /fep/xxxx/index.md or readme.md or fep-xxxx.md (not sure what to specify exactly; weak preference for index.md, because this will make static site generation easy; secondary preference for fep-xxxx.md because this retains the filename; weakest preference for readme.md because this will show up in codeberg markdown preview for the /fep/xxxx folder)
  • /fep/xxxx/assets/whatever.png
  • /fep/xxxx/context.jsonld (usage specified in 9606)

/feps/fep-xxxx.md remains as legacy; it is expected to migrate away from using this, perhaps by editing existing files to point to the new location? something like /feps/fep-xxxx.md can be edited to contain something like this:

[moved to /fep/xxxx](https://codeberg.org/fediverse/fep/src/branch/main/fep/xxxx/)

or otherwise a symlink, which doesn’t work in codeberg’s markdown preview (see [Better symlink support] Follow relative symbolic links in GUI if they are available · Issue #12219 · go-gitea/gitea · GitHub for that issue i guess) but works on pretty much anything else that interfaces with a filesystem:

../fep/xxxx/

of the two, i have a slight preference for the markdown link because i expect the majority of people looking at the old file path to be doing so on codeberg, not in a locally cloned copy of the repo (where the structure should be clear, because they have the whole repo already)

1 Like

Open considerations:

  1. This PR copies feps/fep-xxxx.md to fep/xxxx/fep-xxxx.md for now. There is some consideration for naming it index.md instead, in order to ease with potential future static site generation via CI/CD. Imagine a CI/CD task that clones the repo and generates a proper site using fep as the content directory. (The idea is that this site may then be served to anyone requesting text/html representations of the https://w3id.org/fep/xxxx URI following the specifications laid out in FEP-9606.)

  2. This PR does not yet delete any old paths. Everything in feps/ has been edited to contain a Markdown link to the new location.

Rationale:

  • We have encountered FEPs that wish to create their own assets, and the current structure is confusingly laid out. Asset colocation is widely considered a “best practice” for this sort of scenario. Particularly in cases where the rest of the repo’s structure may potentially change in the future, asset colocation prevents any FEP-specific links from breaking because those links can be written relative to their FEP root.

  • To ease PURL resolution, context documents can be considered sidecar assets to each FEP that defines extension terms. The mechanism for this is again described in FEP-9606. Redirection rules can be simplified to use less conditions, since the base folder remains the same.

Next steps:

  • Edit the README.md to update the instructions for submitting a new FEP (pending open consideration 1)
  • Set a timeline for when or if the old feps/ directory should be removed (pending open consideration 2)
  • Merge the PR
2 Likes

Thanks for this PR. I have no objections to its content, however before it gets merged I’d like to see more confirmation from others that that the current layout is sufficiently problematic that it needs to be fixed. I think this is an important test for the community to apply so we solve the right problems.

I approved the PR. Thank a lot for doing this work, @trwnh :green_heart:

By the way, we already have this page: About the Fediverse Enhancement Proposals - SocialHub but it hasn’t been updated in a while