Anyone can propose a change to FEP-a4ed using any method listed in SUBMISSION.md file. The change must be approved by at least two editors (one of them could be the submitter). If the change is substantial, it should not be accepted until at least 1 week passes after the last update (to give editors enough time to review it). Proposed minor corrections could be accepted immediately after getting two approvals from editors.
I have comments:
First, I feel that âsubstantialâ is too vague. I would like some examples
Any change to the folder structure
Any change to the submission process
Any change to the file format
I think any change to FEP-a4ed should be announced and discussed on SocialHub. For me codeberg holds the state of FEP not the process. We might want a FEP Governance category for it. I also failed to create governance tag.
The change must be approved by at least two editors (one of them could be the submitter).
I think important decisions should require approval of the majority of editors. However, currently only two editors (out of 6) review pull requests, so I picked the number 2 to keep things going.
The list of editors was revised last time in 2022. It would be good to repeat this procedure before the end of the year.
Anyone can propose a change to FEP-a4ed (or other documents related to the FEP process) using any method listed in SUBMISSION.md file. The change must be approved by at least two editors (one of them could be the submitter). If the change is substantial (i.e. not a correction of a typo or of a broken link), it should not be accepted until at least 1 week passes after the last update (to give editors enough time to review it). Proposed minor corrections could be accepted immediately after getting two approvals from editors.
Itâs easier to say what constitutes a non-substantial change.
The proposed change requires only one person besides the submitter to accept the change: this is not enough. The submitter should not be counted in this number, so at least three people must convene to accept a change.
The proposed change allows changes to be made according to âany method listed in SUBMISSION.mdâ (plural), but this file only lists one method: Codeberg, which implies not requiring open discussion process on the SocialHub.
The proposed change requires one week (after last edition) for changes to be accepted: this is not enough for people to get awareness of the change and time to review or discuss it in times of information overload.
Here are my suggestions:
at least 3 people should be agreeing on the changes â these people should have good standing with the community, e.g., with commit access or reviewer membership in the Fediverse team, or moderator/host access on the SocialHub, or chair of the SocialCG, or @trust_level_2 here.
the SUBMISSION.md should enforce mentioning new issues on the SocialHub so that the whole community gains quick awareness of changes and keeps the process going on here.
the delay before a change is adopted should be increased to a month. In the meantime, a proposed change may be âpendingâ after a week to ensure it becomes visible. Maybe there could be a âstagingâ branch for upcoming FEP changes?
A pull request should not be merged if a single member of the community disapproves of it without their issues having been appropriately addressed.
It should be made clear that all such pull requests must be in accordance with FEP goals: âThe goal of a FEP is to improve interoperability and well-being of diverse services, applications and communities that form the Fediverse.â. I would also add the objective of keeping FEP a light weight process to this list. This means that a significant pull request that does not further these goals or makes FEP more heavy weight, should be rejected.
I think at the moment we donât have 3 editors who can regularly review changes (see my previous comment). The number can be changed later though.
People who are not editors may express opinions, but they canât make decisions, because these decisions directly affect FEP editors who do the chores.
Such requirement should probably go into FEP-a4ed. SUBMISSION.md is just a convenient way to refer to âall submission methodsâ without repeating them (currently thereâs only one but we can expect more in the future).
Also, I think this topic is separate from the current one and should be tackled in a separate pull request. Again, the discussion on task management feels relevant: Task management at FEP repository
No strong opinion on merge delay. @helge do you support 1 month suggestion?
We can also use issue labels.
This could become a vector of abuse. Maybe only FEP editors should have the veto power?
How would you like to codify this idea? Do you think we should make section âScope and objectivesâ unchangeable, like a constitution?
I would support merging as-is and bumping number when the editorial board swells to 4 or 5
+1 discuss elsewhere.
+1 to using âpendingâ label or equivalent (in Codeberg > in the doc)
+1 to silverpill. so-called âvetocracyâ is a failure mode to take seriously-- Iâve seen some XIP processes crash and burn on veto rights without countermeasures! even if itâs not malicious or interpersonal âabuseâ, it can still devolve quite naturally and easily into abuse of process, which can really hurt the legitimacy of the process or buy-in from document contibutors if they see a substantial risk or frequency of documents âstalling outâ after a lot of work. even making a -1 from any editor a blocker to merging a document can be a failure mode if there is no counterweight to individual editors going commando on their pet issues. counterweights include editorial board membership being challengeable/revocable by the rest of the editorial group, etc etc. sorry to âgo commandoâ myself but I have strong feelings on this one!
I wouldnât overthink this or overspecify this. Iâm not sure we want to lock ourselves into status quo, and how âlightweightâ or âheavyweightâ the process is strikes me as a fundamentally subjective judgment to begin with, rather than a self-evidently good or permanent property of the process. Trying to codify or make immutable such judgments strikes me as having only downsides and no upside, except in that it saves editors having to defend their decisions by embedding a cudgel in their âconstitutionâ
I have another thing that should be blocking to update FEP-a4ed. We currently have some python scripts that handle some of the manual work for the FEP process. If one makes change to the FEP document format, these scripts need to be maintained. So changes that increase the maintenance burden should be discussed and someone needs to volunteer to do the work.
Iâm writing this due to calls for YAML frontmatter. I must say that this is probably a bad idea. YAML is hard to work with when modifying it using a script. As evidence: The first FAQ entry in the PyYAML documentation is how to get YAML outputted in a specific format. One will face similar issues, if one starts automatically update frontmatters for FEPs. My recommendation: Donât. Stick with key value pairs.
That and changing 1 week to 1 month. Then I think Iâm happy with it.
Anyone can propose a change to FEP-a4ed (or other documents related to the FEP process) using any method listed in SUBMISSION.md file. The change must be approved by at least two editors (one of them could be the submitter). For any part of the FEP process, there must be a sufficient number of editors who agreed to maintain. Changes should not be accepted before at least 1 month passes, to give editors and the community time to review them and provide feedback
Minor changes (i.e. not a correction of a typo or of a broken link), can be accepted immediately after getting two approvals from editors.
I strongly disagree that itâs a bad idea or that itâs overly difficult to work with. It is YAML (in a Codeberg context) whether we use a restricted subset of YAML or not. That FAQ entry doesnât imply any major difficulty. Itâs normal for libraries like this (and others, like JSON or XML formatters) to have options for different styles of formatting. Depending on what youâre trying to do, itâs not always necessary to parse and dump the YAML. Simple changes can often manipulate the frontmatter as text context (appending lines, etc.).
You suggest sticking with key value pairs. I assume youâre suggesting that we should only use string-typed values (a list or a dictionary is a value too, as examples). If not, then please ignore my comments. If so, then maybe the restriction could be extended to only allow string-typed or list-typed values (non-recursive). I understand that allowing all YAML features is unnecessary for frontmatter purposes. However, I think only allowing string-typed values and using ad-hoc strings for list representations is unnecessarily restrictive and creates difficulties for metadata consumers.
If thereâs a technical blocker with supporting YAML lists related to the tooling scripts, Iâd be happy to help with that.
)