FEP-a4ed: The Fediverse Enhancement Proposal Process

A small update to FEP-a4ed just got merged. I hope this addresses the issues raised here. Quick summary:

  • Identifiers are now only 4 characters long (FEP-a4ed instead of FEP-a4edc7b). Slightly more memorable at a probably acceptable chance of collision.
  • Updated IETF Terminology draft to latest version (thanks @aschrijver)
  • Add a SUBMISSION_METHODS file to the root of the repository that includes the exact address of the repo and how to submit a proposal. This addressed the issue brought up by @Claire and at the same time allows the repo to be moved if ever necessary.

See the pull request for a diff: https://git.activitypub.dev/ActivityPubDev/Fediverse-Enhancement-Proposals/pulls/5

Some notes on the proposal status (as an illustration how submission process works):

  • It has been 46 days since FEP-a4ed was submitted (16th October 2020).
  • The initial draft period lasts for at least 60 days - until the 15th of December 2020.
  • On the 15th of December (or shortly after) I will request final comments on the proposal from you, the community. If there are no objections the propsoal will be finalized (receive status FINAL 14 days after - on the 29th of December)

The submission process takes a bit of time. The hope is that such a long time allows comments, suggestions and objections to be made without haste.

Personally, I am happy with the pace. The submission has not required constant attention from me and the work involved is reasonable.

1 Like

Nice work!

I think what’s still missing is what happens when things get FINAL. We have created something authoritative now, right? So that should be advertised on a prominent location preferably. I wonder about the current location being most suitable for that. I see git.activitypub.dev more as the workspace for FEP’s, and ideally, maybe FINAL FEB’s should be mentioned on activitypub.rocks landing page (though just linked to the repo with some info to it, that would be enough imho). Activitypub.rocks is #1 search result for ActivityPub and authoritative for the spec (besides the W3C, of course).

Also a topic with pointers and explainer might be permanently pinned to the top of this forum: “FEP’s: Wanna enhance the Fediverse? Here’s how the process works”

Edit: Oh, and imho the README should have a list or table of FEP’s in the repo, with link + brief description + status.

Some other feedback:

  • In Readme: “[After submission] you are now required to …” and in FEP-a4ed “Authors are responsible …”. I find the latter a better, more friendly description.
  • But what if someone started with good intention, FEP accepted, then slacks off in doing community outreach, asks for finalization, and after 2wks… it becomes FINAL?

I am not familiar with FEP processes, but the last point may mean that hardly anyone noticed the FEP in the first place, and the FEP is of little value or detrimental to the quality of the process itself. Maybe there should be an additional step, where ‘the community’ feedback must be collected in the repo (e.g. as issue comments), even if to explicitly state “I stand behind this proposal” which is as valuable as discussions (especially when coming directly from fedi app maintainers).

Additionally either the FEP repo or activitypub.rocks or both might keep track of projects that have actually adopted / incorporated / implemented the FEP, which serves to demontrate its usefulness, and is both encouragement for others to adopt, as well as providing reference material (e.g. example code) for doing so.

Hello,

I created a new topic to host this discussion so it provides:

  1. a direct link to the repository entry
  2. a clean first post to host the future final version

I described the whole thing in About the Fediverse Enhancement Proposals.

1 Like

Absolutely. The idea was to first concentrate on the FEP documents itself and once it is in half-way decent form allow it to be presented in a nicer format. The document structure of FEPs was intentionally made easy to use from static-site generators. Some ideas on how and where to present FEPs in a nicer format:

  • library.activitypub.dev (cc @cjs)
  • activitypub.rocks: I’m all for adding FEPs there as well. I can submit a patch that makes haunt read FEPs and display them. However, who controls activitypub.rocks? Where and who hosts the site? Who decides what goes on there? And why not move git.activitypub.dev to git.activitypub.rocks? I think this should be forked to a topic for itself.

Props to @how for doing this.

This is something that can be very well be done by a static-site generator (or similar) and I am a bit reluctant to add it, as it does add considerable maintenance burden.

Ok, if we concentrate on doing this in a nice presentation of FEPs (e.g. library.activitypub.dev) and revisit index in README after?

:+1: done (https://git.activitypub.dev/ActivityPubDev/Fediverse-Enhancement-Proposals/pulls/6)

The default path is: DRAFT -> WITHDRAWN. And if interest in a proposal fades this is what would happen.

There is a lot of room for interpretation what is required for a proposal to be come final. FEP-a4ed says:

  - If there are no community objections within 14 days and the authors can show that they have initiated sufficient awareness and discussion of the proposal, an editor will set the status of the submission to `FINAL`.

The “burden-of-proof” lies with the author but what exactly is “sufficient awareness and discussion” is vague.

I hope a general understanding of what this means will develop naturally and we do not have to specify strictly the form and medium of discussion.

I’d suggest leaving it out of FEP-a4ed. In the future when we have tested the waters and seen what kind of discussions work, we might have a FEP-6c17: Best Practices for Initiating Discussion and Collecting Feedback on a FEP proposal. What do you think?

I invite you to consider yourself familiar with the process. :slight_smile:

There should not be much magic to it. The goal of FEP-a4ed is to understandably and correctly describe the process.

1 Like

Yes, that would also work if the README contains a clear reference to the list. Agreed.

Super idea.

Woot, thx   :partying_face:

Some remarks regarding FEP-f1d5: NodeInfo in Fediverse Software

The discussion of a possible security issue took place in a toot, and was followed-up on the forum, where - in this situation - it may be decided that this should not be documented in the FEP (as it is arguably a ‘security-by-obscurity’ issue that makes matters worse), BUT…

The issue was a valid point that was brought up, and the decision not to include is possibly made somewhere deep in a long forum discussion thread. Not only should the original author be aware of it, but any other AP implementer should too.

Therefore 2 things may be part of the FEP document format:

  • A list of open issues, or rather decision points, where the outcome may be documented too e.g.: “We’ll avoid security-by-obscurity and include version information”
  • A link to the forum discussion topic / post where the decision was argumented and taken.

My personal vote is for the second option, for FEPs to link to:

1 Like

@cjs yes, that would be easiest maintenance-wise, and I think that this should be included in the FEP template, imho.

On the other point my experience is that discussion threads (such as this one with now 18 comments, or the Followers Sync FEP with 41 posts) are so easily TL;DR’ed, where they just respond to the most recent comment. You could say it is their fault then if they missed an open issue or decision in parsing the history of the thread. This saves the author some time, but shifts the burden to each and every reader.

The authors are probably most deeply aware of all ins and outs of the FEP, and are responsible for the collection of feedback already. Part of that might include providing this summary of open issues / decision points that allow readers to drill into the subject matter quickly.

Right now the issue tracker in the FEP repo is unused. The workflow might be that - as soon as an open issue pops up in discussion - someone (e.g. the author) creates a FEP-related issue, with an appropriate label, and maybe a user assignment indicating who is responsible for dealing with it. So for example:

FEP-f1d5: Include software.version in NodeInfo?   [decision]

Assigned to: @cjs
Discussion: https://socialhub.activitypub.rocks/t/fep-f1d5-nodeinfo-in-fediverse-software/1190/4

@macgirvin proposed to exclude software.version from NodeInfo because inclusion might pose a security issue.

The issue need not be larger than that. Discussion is on the forum. Once a clear agreement is reached the issue is updated with a [resolved] label and some text, then closed. Before the FEP enters finalization stage the Issues should be added to References section (or a separate section just for issues).

(Note that you could also create individual labels for each FEP, and then there’s no need to create a list, but instead you include the url to the filtered issues on that label in References section)

Sure, this would work. There should be an easy navigation from the static site to the markdown doc to PR to in the repo then.

I guess in my most recent comments above, it indicates there’s already a need for this, but in a slightly more specific and practical manner (if y’all agree with that feedback, that is).

I have a couple of questions about the FEP process.

  • If I’m proposing a technical thing, is it preferable for it to have been implemented already?
  • If I’m adding fields to an ActivityPub object, and I expect them to be used widely in the future, which namespace should I be using? My own, i.e. http://smithereen.software/ns#? ActivityStreams? Something else?
1 Like

I am reluctant to add such a requirement. I do not think that discussion should be referenced from the FEP itself. The FEP by itself should be enough to understand the matter.

I think that is a good idea.

I have created tracking issues for the 3 DRAFT FEPs:

Pull request #13 includes a GitTea template for these tracking issues.

Also added as interim solution in #13.

I have also increased the time before a FEP automatically goes from DRAFT to WITHDRAWN from 90 days to 120 days. This is mostly because I have been away and almost missed the date…Generally a bit more time can not harm.

Would you want to submit a FEP addressing this?

2 Likes

I think it is nice to have at least one working implementation (good for figuring out all the things one forgets), but there is no strict requirement.

Excellent question.

FEPs do not have any control of what should be added to ActivityStreams. Maybe it might make sense to add a FEP namespace (e.g. https://activitypub.dev/fep/ns#) where things can be added but in the mean time I think it is better to use your own.

4 Likes

You mean a FEP to update the FEP FEP :wink:

I may pick this up at a later date. There’s a good basis now, with which we can run for the moment. See what makes sense or not later on.


Something else. Yesterday some interesting background on FEP-like processes:

And a HN discussion about the article (80+ comments).

NABC model from Stanford was mentioned, which stands for Need, Approach, Benefit, Competitors. Both Need and Competitors are most interesting. Separatng Need from Approach is great for the understanding of the author, while Competitors “is the part the authors have to consider competitors of their proposal.”. It has the effect of:

“Thinking about an alternative solution instead of their suggestion requires people to focus on the problem instead of blindly loving and defending their solutions.”

Overall “The process seeks a consent-based environment, not a consensus-based one [AND] brings accountability , as well”

A post was merged into an existing topic: Business domains, LD vocabulary extensions and namespaces

I kindly request final comments on “FEP-a4ed: The Fediverse Enhancement Proposal Process”.

Notable changes since the proposal has been received:

  • Reduce number of characters in identifier to 4. More readable and good enough.
  • Specify the EDITORS.md and SUBMISSION.md files.
  • Increase time before proposal is auto-withdrawn to 120 days.
  • Update some references.

See also the tracking issue.

I have requested finalization in 14 days. If there are no objections, the proposal will become final on the 18th of January.

Thanks!

2 Likes

@pukkamustard I finally read FEP-a4ed and it looks great. A really solid basis for coherent communication in the community.

There’s scope for publishing FINAL FEPs as Social Incubator CG Reports if there’s interest from the community in producing documents with the w3c header on, under w3.org. As well as being preserved at a persistent URL, they have the advantage of being easily submitable to Working Groups as input documents for formal standardisation in future.

2 Likes

I also think the FEP process could be a good way to incubate extensions to AS2, which can then be adopted through a proposal to the CG and added to the AS2 namespace. Since the CG had not manage to come up with a process for this so far, we can talk about adopting the FEP for it at some point.

1 Like

Sorry for being a bit late to the party. My gripes with the process so far were:

  • there no being clear way to submit the FEP, but that has been fixed
  • the FEP IDs changing, but I expect this won’t change again

The current document looks good, although I wonder if it should provide guidance and venues for authors to get discussion and feedback on their proposals.

One very minor typo: BitTorrent Enhancment Proposal Process → BitTorrent Enhancement Proposal Process

Claire via SocialHub noreply@socialhub.activitypub.rocks writes:

Sorry for being a bit late to the party. My gripes with the
process so far were:

  • there no being clear way to submit the FEP, but that has been
    fixed

:+1:

  • the FEP IDs changing, but I expect this won’t change again

Yes, sorry about that. FEP-8fcf and FEP-f1d5 were a bit special as
they were submitted before the process itself was finalized. This
should not happen again.

The current document looks good, although I wonder if it should
provide guidance and venues for authors to get discussion and
feedback on their proposals.

This is an important point that has been brought up previously
(see thread above).

I’m very reluctant to give any concrete recommendations or
requirements on venues for discussing proposal. My hope is that
such venues will develop naturally. When these are established it
might make sense to document these venues. This can be done in an
additional FEP. In best case these would be venues that fit with
the spirit of the Fediverse and are federated/decentralized (as
opposed to this highly centralized forum).

One very minor typo: BitTorrent Enhancment Proposal Process →
BitTorrent Enhancement Proposal Process

Thanks for the catch. Fixed with

Feedback AFTER the FEP became FINAL starts here …


This FEP has become FINAL and…

A proposal with status FINAL can not be changed or updated.

Now suppose I would like to change it. What’s the procedure? Should one write another FEP that suppercedes the current one if it becomes FINAL. If so, how do we document that so it is clear to everyone? Or should FEP’s be Versioned instead?

The change I am thinking about is following:

  • While in DRAFT mode there should not be a Timer that is ticking (the 60 day period). This is the stage where you prepare your proposal before it is ready for the world.
  • Add an additional workflow step PROPOSED where the 60-day review period starts.

The workflow then looks as follows:

                                                          +-------+
                                                +-------> | FINAL | 
                                                |         +-------+
         +-------+          +----------+        |
-------->| DRAFT | -------->| PROPOSED |--------+
         +-------+          +----------+        |
             ^                                  |         +-----------+
             |                                  +-------> | WITHDRAWN |
             |                                            +-----------+
             |                                                  |
             +--------------------------------------------------+

Why extend?

  • So all drafts being prepared are in one place.
  • So you can work with others to hone it together before actually proposing.

For the case where a new FEP supercedes another this may be reflected in its state, plus a reference to the superceding FEP is added to the old one. Maybe a better state name is in order e.g. ARCHIVED or even (maybe) DEPRECATED in some cases…

                                                          +-------+                +------------+
                                                +-------> | FINAL |--[other-FEP]-->| SUPERCEDED |
                                                |         +-------+                +------------+
         +-------+          +----------+        |
-------->| DRAFT | -------->| PROPOSED |--------+
         +-------+          +----------+        |
             ^                                  |         +-----------+
             |                                  +-------> | WITHDRAWN |
             |                                            +-----------+
             |                                                  |
             +--------------------------------------------------+

CC @pukkamustard @cjs

1 Like