XEP-0001 Changes to reflect current practice wrt XEP Authors
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.
On 12/15/24 7:57 AM, Dave Cridland wrote:
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?)
In the recent past I've seen specs submitted via email (e.g., MUC Slow Mode). But it does happen via PR and we might even want to settle on that as the preferred method. I'd defer to Daniel on that. Peter
On Mon, Dec 16, 2024 at 3:32 AM Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 12/15/24 7:57 AM, Dave Cridland wrote:
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?)
In the recent past I've seen specs submitted via email (e.g., MUC Slow Mode). But it does happen via PR and we might even want to settle on that as the preferred method. I'd defer to Daniel on that.
Slow mode was submitted as PR after I instructed the author to do so. And yes PRs is what I prefer and what I strongly suggest we use going forward.
On Mon, 16 Dec 2024 at 07:22, Daniel Gultsch <daniel@gultsch.de> wrote:
On Mon, Dec 16, 2024 at 3:32 AM Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 12/15/24 7:57 AM, Dave Cridland wrote:
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?)
In the recent past I've seen specs submitted via email (e.g., MUC Slow Mode). But it does happen via PR and we might even want to settle on that as the preferred method. I'd defer to Daniel on that.
Slow mode was submitted as PR after I instructed the author to do so. And yes PRs is what I prefer and what I strongly suggest we use going forward.
OK, so I have multiple hats to wear, and therefore multiple responses: Process Documenting Hat: We should definitely document that, since it deviates entirely from our published submission. I'll get onto that (possibly on the train I'm on). Should be an easy PR against XEP-0143. Personal Hat: This - as well as the proposed changes I've made to XEP-0001 - effectively mandates that at least one author has a GitHub account, or there's an un-named person with a GitHub account who's doing a lot of the heavy lifting. Is this something we're happy with? I seem to recall in the past some people have objected to a GitHub account being a requirement. This might not be awful; but I think if we are formalizing this we might want to have a named role (or perhaps more sensibly, expand the existing Document Shepherd role) to cover this. Should the Document Shepherd be listed on the XEP alongside the Author(s)? Dave
On 16/12/2024 08.22, Daniel Gultsch wrote:
On Mon, Dec 16, 2024 at 3:32 AM Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 12/15/24 7:57 AM, Dave Cridland wrote:
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?)
In the recent past I've seen specs submitted via email (e.g., MUC Slow Mode). But it does happen via PR and we might even want to settle on that as the preferred method. I'd defer to Daniel on that.
Slow mode was submitted as PR after I instructed the author to do so. And yes PRs is what I prefer and what I strongly suggest we use going forward. I'd like us to keep a non-github XEP submission door open. Therefore, I would offer myself to process XEP submissions via editor@xmpp.org. Only if it's ok with Daniel, of course.
This would require me to be added to the editor@ alias and probably also mean that I officially need to rejoin the XEP editors team (of which I once was part of and where I did some processing, but was later correctly dropped due to inactivity). - Flow
On 12/17/24 2:40 AM, Florian Schmaus wrote:
On 16/12/2024 08.22, Daniel Gultsch wrote:
On Mon, Dec 16, 2024 at 3:32 AM Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 12/15/24 7:57 AM, Dave Cridland wrote:
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?)
In the recent past I've seen specs submitted via email (e.g., MUC Slow Mode). But it does happen via PR and we might even want to settle on that as the preferred method. I'd defer to Daniel on that.
Slow mode was submitted as PR after I instructed the author to do so. And yes PRs is what I prefer and what I strongly suggest we use going forward. I'd like us to keep a non-github XEP submission door open. Therefore, I would offer myself to process XEP submissions via editor@xmpp.org. Only if it's ok with Daniel, of course.
It sounds like there are two possibilities here: 1. We have a different processing path for email submission (not via PR). 2. Someone on the editor team (or a dedicated document shepherd) acts as "GitHub gateway" and submits the PR on behalf of the author. It seems that #2 would preserve more of the processing path and thus would be preferable.
This would require me to be added to the editor@ alias and probably also mean that I officially need to rejoin the XEP editors team (of which I once was part of and where I did some processing, but was later correctly dropped due to inactivity).
No concerns here with that. Administrivia: For the record, the editor@xmpp.org email address is actually a mailman list, not an alias. This implies that we need to manage subscriptions to the list, weed out copious amounts of spam (which I currently do), etc. We might consider making it an alias instead, unless we feel the need for list archives. Peter
On Tue, 17 Dec 2024 at 22:12, Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 12/17/24 2:40 AM, Florian Schmaus wrote:
On 16/12/2024 08.22, Daniel Gultsch wrote:
On Mon, Dec 16, 2024 at 3:32 AM Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 12/15/24 7:57 AM, Dave Cridland wrote:
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?)
In the recent past I've seen specs submitted via email (e.g., MUC Slow Mode). But it does happen via PR and we might even want to settle on that as the preferred method. I'd defer to Daniel on that.
Slow mode was submitted as PR after I instructed the author to do so. And yes PRs is what I prefer and what I strongly suggest we use going forward. I'd like us to keep a non-github XEP submission door open. Therefore, I would offer myself to process XEP submissions via editor@xmpp.org. Only if it's ok with Daniel, of course.
It sounds like there are two possibilities here:
1. We have a different processing path for email submission (not via PR).
2. Someone on the editor team (or a dedicated document shepherd) acts as "GitHub gateway" and submits the PR on behalf of the author.
It seems that #2 would preserve more of the processing path and thus would be preferable.
I think there's a third option, which is to move the responsibility for processing non-GitHub PRs onto the submitter, and have them find a volunteer to handle it each time (a Document Shepherd, additional Author, or whatever). I worry that if there's a body on the Editorial team who handles this very rare case, it'll likely mean that when it's needed, we've mostly forgotten who has this role, or they've drifted away, or whatever. Once submitted, it's the Author's responsibility to do the updates by PR as well, so this is a task for the lifetime of each XEP (like the Author, really). If a submitter cannot find anyone on the standards list or amongst the people they know willing to help handle this part of the Author role, then I think that suggests quite a bit about how much interest there is in the XEP. Furthermore, I think this is essentially a mild formalisation on what the existing de-facto process is; so absent a strong reason to chnage the existing process, I'd rather we document something that matches. (I'll make a PR against XEP-0143 with concrete text on Friday)
This would require me to be added to the editor@ alias and probably also mean that I officially need to rejoin the XEP editors team (of which I once was part of and where I did some processing, but was later correctly dropped due to inactivity).
No concerns here with that.
FWIW, I've no concerns with Florian rejoining the Editorial team in the slightest, and if Florian wants to pick up these cases, that's also great - and compatible with my suggestion above. I just don't think this is the right way to formalize this particular problem across the long term.
Administrivia: For the record, the editor@xmpp.org email address is actually a mailman list, not an alias. This implies that we need to manage subscriptions to the list, weed out copious amounts of spam (which I currently do), etc. We might consider making it an alias instead, unless we feel the need for list archives.
Peter
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
On Wed, Dec 18, 2024 at 11:07 AM Dave Cridland <dave@cridland.net> wrote:
I think there's a third option, which is to move the responsibility for processing non-GitHub PRs onto the submitter, and have them find a volunteer to handle it each time (a Document Shepherd, additional Author, or whatever). I worry that if there's a body on the Editorial team who handles this very rare case, it'll likely mean that when it's needed, we've mostly forgotten who has this role, or they've drifted away, or whatever. Once submitted, it's the Author's responsibility to do the updates by PR as well, so this is a task for the lifetime of each XEP (like the Author, really).
If a submitter cannot find anyone on the standards list or amongst the people they know willing to help handle this part of the Author role, then I think that suggests quite a bit about how much interest there is in the XEP.
Furthermore, I think this is essentially a mild formalisation on what the existing de-facto process is; so absent a strong reason to chnage the existing process, I'd rather we document something that matches.
(I'll make a PR against XEP-0143 with concrete text on Friday)
I’m in support of this third option. cheers Daniel
Le mercredi 18 décembre 2024, 11:07:25 heure normale d’Europe centrale Dave Cridland a écrit :
On Tue, 17 Dec 2024 at 22:12, Peter Saint-Andre <stpeter@stpeter.im> wrote:
I think there's a third option, which is to move the responsibility for processing non-GitHub PRs onto the submitter, and have them find a volunteer to handle it each time (a Document Shepherd, additional Author, or whatever). I worry that if there's a body on the Editorial team who handles this very rare case, it'll likely mean that when it's needed, we've mostly forgotten who has this role, or they've drifted away, or whatever. Once submitted, it's the Author's responsibility to do the updates by PR as well, so this is a task for the lifetime of each XEP (like the Author, really).
If a submitter cannot find anyone on the standards list or amongst the people they know willing to help handle this part of the Author role, then I think that suggests quite a bit about how much interest there is in the XEP.
Furthermore, I think this is essentially a mild formalisation on what the existing de-facto process is; so absent a strong reason to chnage the existing process, I'd rather we document something that matches.
(I'll make a PR against XEP-0143 with concrete text on Friday)
I think that making it nearly-mandatory to register an account on a service from a private company is a problem. It's totally understandable that people don't want to create an account on GitHub (I've avoided it myself for a long time), and asking potential first-time contributors to look for help themselves can be highly discouraging. At the very least, there should be an easy process to ask for help, a list of people to contact, or an automated message requesting assistance when a patch is received by email. As you mentioned yourself, this case is currently rare, so it shouldn't be a huge problem. I don't say that accepting patches by email is a must, but there should be an option that doesn't require creating an account on a private company's service, even if it's not used often. Thanks, Goffi
On Wed, 18 Dec 2024 at 14:20, Goffi <goffi@goffi.org> wrote:
Le mercredi 18 décembre 2024, 11:07:25 heure normale d’Europe centrale Dave Cridland a écrit :
On Tue, 17 Dec 2024 at 22:12, Peter Saint-Andre <stpeter@stpeter.im> wrote:
I think there's a third option, which is to move the responsibility for processing non-GitHub PRs onto the submitter, and have them find a volunteer to handle it each time (a Document Shepherd, additional Author, or whatever). I worry that if there's a body on the Editorial team who handles this very rare case, it'll likely mean that when it's needed, we've mostly forgotten who has this role, or they've drifted away, or whatever. Once submitted, it's the Author's responsibility to do the updates by PR as well, so this is a task for the lifetime of each XEP (like the Author, really).
If a submitter cannot find anyone on the standards list or amongst the people they know willing to help handle this part of the Author role, then I think that suggests quite a bit about how much interest there is in the XEP.
Furthermore, I think this is essentially a mild formalisation on what the existing de-facto process is; so absent a strong reason to chnage the existing process, I'd rather we document something that matches.
(I'll make a PR against XEP-0143 with concrete text on Friday)
I think that making it nearly-mandatory to register an account on a service from a private company is a problem. It's totally understandable that people don't want to create an account on GitHub (I've avoided it myself for a long time), and asking potential first-time contributors to look for help themselves can be highly discouraging.
Totally agreed.
At the very least, there should be an easy process to ask for help, a list of people to contact, or an automated message requesting assistance when a patch is received by email. As you mentioned yourself, this case is currently rare, so it shouldn't be a huge problem.
Is something like "Do a PR, but if you can't, send it to standards@ and ask for help?" enough here? Currently, Florian is happy to handle all such requests; but I don't think it's fair on him to rely on his continued availability and kindness.
I don't say that accepting patches by email is a must, but there should be an option that doesn't require creating an account on a private company's service, even if it's not used often.
I do 100% sympathise. However, options such as running our own version control, or insisting that the Editor handles emailed patches and submissions, seem to put the additional load on the wrong people too. I do think anything we do here is inevitably a compromise, I'm hoping we can find one we're all equally, and minimally, unhappy with. Dave.
------ Original Message ------ From "Dave Cridland" <dave@cridland.net> To "XMPP Standards" <standards@xmpp.org> Date 18/12/2024 14:50:16 Subject [Standards] Re: XEP-0001 Changes to reflect current practice wrt XEP Authors
On Wed, 18 Dec 2024 at 14:20, Goffi <goffi@goffi.org> wrote:
I don't say that accepting patches by email is a must, but there should be an option that doesn't require creating an account on a private company's service, even if it's not used often.
I do 100% sympathise. However, options such as running our own version control, or insisting that the Editor handles emailed patches and submissions, seem to put the additional load on the wrong people too.
I do think anything we do here is inevitably a compromise, I'm hoping we can find one we're all equally, and minimally, unhappy with.
FWIW, I don't think everyone being equally unhappy is really the aim here. We have one active Editor, who says they're not likely to process email submissions. I vaguely remember it might have been processing email submissions that caused the previous Editor (me) to finally lose the will, and we've burned out many Editors over the years - so I think our practical aim has to be minimising everyone else's unhappiness secondary to being able to keep Editors. (Side note, I admire Florian's "I care about this so I'll volunteer for the extra work", rather than trying to push more onto Daniel) I don't think requiring GitHub accounts is the 'right thing' in principle, but I think needing everything to be a GitHub PR if that's what Editors want is what we practically need to do, and the "If you can't GitHub please mail standards@ and find someone there to help you" suggestion is pragmatic - at the moment we have Florian volunteering to pick that up, and if in the future it stops being viable we can reassess (as with all things). /K
Le mercredi 18 décembre 2024, 16:03:34 heure normale d’Europe centrale Kevin Smith a écrit :
I don't think requiring GitHub accounts is the 'right thing' in principle, but I think needing everything to be a GitHub PR if that's what Editors want is what we practically need to do, and the "If you can't GitHub please mail standards@ and find someone there to help you" suggestion is pragmatic - at the moment we have Florian volunteering to pick that up, and if in the future it stops being viable we can reassess (as with all things).
Note that I don't want to put any more burden on Daniel, or anybody, the message suggested by Dave is good IMHO. I just want to avoid that contributors have to look by themselves who to contact, and why their contributions is ignored, and finally be discouraged. If their is a clear and easy to find message that preferred option is a PR, and an email patch is a possibility but need to ask for help on standard@, this is fine I guess. Thanks, Goffi
Le mercredi 18 décembre 2024, 15:50:16 heure normale d’Europe centrale Dave Cridland a écrit :
Is something like "Do a PR, but if you can't, send it to standards@ and ask for help?" enough here? Currently, Florian is happy to handle all such requests; but I don't think it's fair on him to rely on his continued availability and kindness.
If it's easy to find, I guess it's an acceptable solution yes. The "write-your- own specification" onboarding page seems to be https://xmpp.org/about/ standards-process/, so that's probably the right location for this message. To be honest, I've had to search for a few minutes to find it, but if somebody is motivated enough to write a specification, it's probably not so hard. Thanks, Goffi
On Wed, 18 Dec 2024 at 16:21, Goffi <goffi@goffi.org> wrote:
Le mercredi 18 décembre 2024, 15:50:16 heure normale d’Europe centrale Dave Cridland a écrit :
Is something like "Do a PR, but if you can't, send it to standards@ and ask for help?" enough here? Currently, Florian is happy to handle all such requests; but I don't think it's fair on him to rely on his continued availability and kindness.
If it's easy to find, I guess it's an acceptable solution yes. The "write-your- own specification" onboarding page seems to be https://xmpp.org/about/ standards-process/ <https://xmpp.org/about/standards-process/>, so that's probably the right location for this message. To be honest, I've had to search for a few minutes to find it, but if somebody is motivated enough to write a specification, it's probably not so hard.
Thanks for that, I'd missed that before. Open (well, Draft) PR against that now.
Le dimanche 15 décembre 2024, 15:57:13 heure normale d’Europe centrale Dave Cridland a écrit :
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.
Hi Dave, Thank you for taking care of this. For the record, experimental XEPs have already been changed without author agreement, AFAIK mostly for minor stuff such as typos. It should probably be written somewhere. Best, Goffi
On Mon, 16 Dec 2024, 20:58 Goffi, <goffi@goffi.org> wrote:
Le dimanche 15 décembre 2024, 15:57:13 heure normale d’Europe centrale Dave Cridland a écrit :
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.
Hi Dave,
Thank you for taking care of this. For the record, experimental XEPs have already been changed without author agreement, AFAIK mostly for minor stuff such as typos. It should probably be written somewhere.
Good point - I'll sprinkle the term "non-editorial" about.
Best, Goffi _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
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@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.
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@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@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.
participants (6)
-
Daniel Gultsch -
Dave Cridland -
Florian Schmaus -
Goffi -
Kevin Smith -
Peter Saint-Andre