15 Dec
2024
15 Dec
'24
7:57 a.m.
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.
15 Dec
15 Dec
7:31 p.m.
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
16 Dec
16 Dec
12:22 a.m.
On Mon, Dec 16, 2024 at 3:32 AM Peter Saint-Andre <stpeter(a)stpeter.im> wrote:
On 12/15/24 7:57 AM, Dave Cridland wrote:
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.
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.
1:30 p.m.
On Mon, 16 Dec 2024 at 07:22, Daniel Gultsch <daniel(a)gultsch.de> wrote:
On Mon, Dec 16, 2024 at 3:32 AM Peter Saint-Andre
<stpeter(a)stpeter.im>
wrote:
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 12/15/24 7:57 AM, Dave Cridland wrote:
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.
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. 
17 Dec
17 Dec
2:40 a.m.
On 16/12/2024 08.22, Daniel Gultsch wrote:
On Mon, Dec 16, 2024 at 3:32 AM Peter Saint-Andre
<stpeter(a)stpeter.im> wrote:
I'd like us to keep a non-github XEP submission door open. Therefore, I
would offer myself to process XEP submissions via editor(a)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/15/24 7:57 AM, Dave Cridland wrote:
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.
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.
3:11 p.m.
On 12/17/24 2:40 AM, Florian Schmaus wrote:
On 16/12/2024 08.22, Daniel Gultsch wrote:
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.
On Mon, Dec 16, 2024 at 3:32 AM Peter Saint-Andre
<stpeter(a)stpeter.im>
wrote:
I'd like us to keep a non-github XEP submission door open. Therefore,
I
would offer myself to process XEP submissions via editor(a)xmpp.org. Only
if it's ok with Daniel, of course.
On 12/15/24 7:57 AM, Dave Cridland wrote:
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. 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. 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(a)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
18 Dec
18 Dec
3:07 a.m.
On Tue, 17 Dec 2024 at 22:12, Peter Saint-Andre <stpeter(a)stpeter.im> wrote:
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.
On 12/17/24 2:40 AM, Florian Schmaus wrote:
I'd like us to keep a non-github XEP submission door open. Therefore,
I
would offer myself to process XEP submissions via editor(a)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)
On 16/12/2024 08.22, Daniel Gultsch wrote:
> On Mon, Dec 16, 2024 at 3:32 AM Peter Saint-Andre <stpeter(a)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. 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(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
5:59 a.m.
On Wed, Dec 18, 2024 at 11:07 AM Dave Cridland <dave(a)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
7:19 a.m.
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(a)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
7:50 a.m.
On Wed, 18 Dec 2024 at 14:20, Goffi <goffi(a)goffi.org> wrote:
Le mercredi 18 décembre 2024, 11:07:25 heure normale
d’Europe centrale
Dave
Cridland a écrit :
Totally agreed.
On Tue, 17 Dec 2024 at 22:12, Peter Saint-Andre
<stpeter(a)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.
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.
8:03 a.m.
New subject: XEP-0001 Changes to reflect current practice wrt XEP Authors
------ Original Message ------
From "Dave Cridland" <dave(a)cridland.net>
To "XMPP Standards" <standards(a)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(a)goffi.org> wrote:
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
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.
9:26 a.m.
New subject: XEP-0001 Changes to reflect current practice wrt XEP Authors
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
9:21 a.m.
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
24 Dec
24 Dec
4:54 a.m.
On Wed, 18 Dec 2024 at 16:21, Goffi <goffi(a)goffi.org> wrote:
Le mercredi 18 décembre 2024, 15:50:16 heure normale
d’Europe centrale
Dave
Cridland a écrit :
Thanks for that, I'd missed that before. Open (well, Draft) PR against that
now.
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.
16 Dec
16 Dec
1:58 p.m.
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
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
(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.
17 Dec
17 Dec
7 a.m.
On Mon, 16 Dec 2024, 20:58 Goffi, <goffi(a)goffi.org> wrote:
Le dimanche 15 décembre 2024, 15:57:13 heure normale
d’Europe centrale
Dave Cridland a écrit :
the
Good point - I'll sprinkle the term "non-editorial" about.
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 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
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
24 Dec
24 Dec
4:58 a.m.
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.
43
days inactive
52
days old
16 comments
6 participants
participants (6)
-
Daniel Gultsch -
Dave Cridland -
Florian Schmaus -
Goffi -
Kevin Smith -
Peter Saint-Andre