You do not appreciate my view of your intention, as I do not appreciate your interference into a process that is documented and that you choose to ignore. You’re very welcome to help “restarting a process that seemed to have hung”, but you should do it following the rules, not taking power. These rules were made to accompany the FEP process and keeping the relevant discussion space slow paced. There are trust levels for a reason – you need to understand how things work. Without @pukkamustard’s and @cjs’ involvement, I don’t see any resolution since they are the ones who are in charge with the FEP process.
Anywhere a discussion makes sense, it should happen. But if a discussion does not happen, probably there’s no need for specification. See for example how the discussion about group has been going on. Only when there’s a need that is shared across implementations can we start thinking about a spec. If the need is not clarified first, how can you generate a spec? This is how XEP, IETF, and other standardization processes work: you discuss first, and from the discussion comes the spec proposal, which is discussed, criticized, refined, etc.
I guess what @weex took for a hung process is a combination of too many specs and not enough time to discuss them. Maybe the FEP process is too short.
Again, the #about topic in the #activitypub:fep category states that the spec topic comes after the FEP in the git repository. The #activitypub category or any of the #software categories are suitable for starting discussions that may lead to specifications. Please just don’t clutter the FEP category with pre-drafts.
See how the Move FEP under a new Standards category discussion moves soooo slowly. It requires time and attention to make things move in a group. That’s a fact of life. We need time to process… I hope that topic will resolve soon though, because indeed Processing the FEP backlog is useful and it would be great to have FEPs resumed.