6 Aug
2025
6 Aug
'25
12:09 p.m.
Possibly everyone (including me) forgot about these, but I've now
remembered and have asked for approval from Board and Council.
Consider this a last call of sorts!
Dave.
On Tue, 24 Dec 2024, 12:58 Dave Cridland, <dave(a)cridland.net> wrote:
More Boring!
* Added Goffi's excellent advice that non-editorial changes don't need
Author permission.
* New PR against XEP-0143: https://github.com/xsf/xeps/pull/1412 (Aside:
Why is the Approving Body Council here?)
* Again, many thanks to Goffi for pointing out the website needs a change
too: https://github.com/xsf/xmpp.org/pull/1466
I believe these are "complete" at this point.
However, I'd prefer community feedback before formally submitting them to
the Approving Bodies.
Dave.
On Sun, 15 Dec 2024 at 14:57, Dave Cridland <dave(a)cridland.net> wrote:
> Hey hey,
>
> Boring incoming:
>
> https://github.com/xsf/xeps/pull/1407
>
> This is draft to avoid the XSF Board accidentally approving it before the
> community has had a chance to discuss.
>
> The main change is the paragraph added in Section 6 (Discussion Process),
> covering changes to the XEP during Experimental:
>
> The XEP author incorporates the feedback by creating source control
>> patches (such as Pull Requests), in line with the preferred method in
>> &xep0143;. Direct changes to an Experimental XEP, such as a contributor
>> providing a patch (or Pull Request on GitHub), are still the responsibility
>> of the XEP author, and are only applied if the XEP author agrees. If a XEP
>> has multiple authors, while agreement is sought from all authors, only
>> those opinions from responsive authors are considered. If the Approving
>> Body feels that the XEP author is not responsive, another author may be
>> added unilaterally by the Approving Body.
>
>
> This is trying to do two things:
>
> 1) Document the existing practice that the XMPP Council has followed,
> whereby changes to Experimental XEPs need "agreement" (PR approval, or
> similar) from the XEP Author.
>
> 2) Document the existing practice that the XMPP Council has followed.
> whereby if a XEP Author isn't responsive (ie, doesn't respond to emails,
> etc) the XMPP Council can add a new XEP Author.
>
> 3) Document the *new practice* that if a contribution isn't a PR, it's
> the XEP Author who is responsible to turn it into one.
>
> The rest of the changes surface and restate existing process/policy/URLs
> and aren't that interesting (well, even less interesting).
>
> There is one additional possible process deviation we should document (or
> call the Process Police out, or something). Submission of a XEP, as per
> XEP-0143, occurs via email tot he Editor. Is this really still the case? Or
> are these now by PR? That'll need changing in XEP-0143, which I'm happy to
> do if that's the case. It'd be nice to have a non-PR variant of the process
> (post here?)
>
> Dave.
>
>