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, <[email protected]> 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 <[email protected]> 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. >> >>
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
