Procedures of the W3C SocialCG

The current handling of issues, which includes closure and apparent disregard of consensus reached on the mailing list, is unfortunately not fostering confidence. Although there’s optimism for future improvement, the lack of a documented, consistently applied, and enforced process is concerning. Unanswered questions and unclear responses further exacerbate the issue.

While it still has much room for improvement, the FEP process appears to be significantly more effective at present.

Perhaps take inspiration from the Nostr NIP process:

Issue list - 20 improvement possibility issues discussed in the last week

Pull requests - 20 pull requests in the last week. As of right now the last one by legendary coder “Uncle” Bob Martin who literally co-authored the “agile” manifisto

Dozens of NIPs merged in the last 6 months.

And this is only one corner of work being done, there are around 500 git projects in progress with their own issue areas.

A Very Simple Process:

Criteria for acceptance of NIPs very simple with just 4 rules

  1. They should be implemented in at least two clients and one relay – when applicable.
  2. They should make sense.
  3. They should be optional and backwards-compatible: care must be taken such that clients and relays that choose to not implement them do not stop working when interacting with the ones that choose to.
  4. There should be no more than one way of doing the same thing.

The W3C, in typical fashion, is having meetings about meetings. Some are more interested in figuring out what titles to give themselves than aiming to fix implementations, issues, or pull request work.

By the time the W3C CG meets next, dozens of issues in nostr will be closed, PRs merged and new work deployed in nostr. The FEPs could take inspiration from this. And in fact go further and do better. Create a vibrant living standard in the fediverse.

I think it’s good for there to be many ways of participating that can appeal to different people’s shifting needs.

For me, it’s not very important that all ways of working have “consistently applied, and enforced process”, because a some people don’t like working in those environments, and I don’t want anyone to be made to work in a way that doesn’t make sense for them. In a volunteer context, I have found this is more likely to make someone refrain from volunteering in the community at all than to lead to them changing the way they do that volunteer work.

Perhaps a way of promoting a diverse pool of volunteers, and accomodating for a diverse set of working preferences, would be to propose a task force with whatever consistently enforced rules you would prefer, and to lead that task force.
I think this is more prosocial than making demands of how others do their volunteer work.

One of the things I personally do like about participating under is the “Positive Work Environment at W3C: Code of Ethics and Professional Conduct”.

the lack of a documented, consistently applied, and enforced process is concerning

With regard to CG process as a whole, this is what I believe is documented, and we should/do follow:

The person who first proposes a group may establish the group’s initial operational agreements. Thereafter, the Chair determines the means by which the group adopts and modifies operational agreements. The Chair must give actual notice to the participants of any material changes to the agreements. Participants may resign from the group if they do not wish to participate under the new agreements.

Note: W3C encourages groups adopt decision-making policies that promote consensus.


It seems to me that if a “Very Simple Process” includes the fourth criteria for NIP acceptance, “no more than one way of doing the same thing,” there may be unfortunate results. The problem is like race condition. The first two clients and relay, by implementing some process and filing a NIP, are able to define the method for addressing some particular requirement. This means that anyone who follows, even if they have a much better method that simply took more time to work out, is essentially blocked by those quicker adopters.

While a simple process has benefits, it also has costs.


Yes you are absolutely right here. This decision has trade-offs. Sometimes, but not always, it favours the first to move. You might build up technical debt that you regret later, in exchange for the sugar rush of early features. Time will tell how well this works out, but my gut tells me the trade-off is worth it. Better to judge a year from now, perhaps.

Edit: perhaps “lightweight” is a more accurate them than “simple”. Illustrates that with relatively few rules, effective and productive processes can be created in open source. Mainly presented as “food for thought”.

Since there’s comparison of approaches, I’d like to remark that SocialHub Community Values Policy is also based on the same W3C Code of Ethics, which is relevant since SocialHub is mentioned on the SWICG as a related channel.