Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Kevin Smith]

On 11 Jun 2021, at 21:57, Ralph Meijer  wrote:
> 
> 
> 
> On June 11, 2021 10:12:31 PM GMT+02:00, Dave Cridland  
> wrote:
>> On Fri, 11 Jun 2021 at 17:10, Kevin Smith  wrote:
>> 
>> * "No person has any automatic right to join a chatroom, or write a XEP."
>> in §3 ought to be something else, since writing a XEP doesn't need the
>> XSF's permission as such.
>> 
>> I'm not sure what this can be, but I accept that writing private extensions
>> using the XEP format and publishing them independently might be considered
>> "writing a XEP", and that's not within the XSF's purview.
> 
> I don't agree here. Hairsplitting below.
> 
> Yes, people are free to create XMPP extensions (lowercase), and I believe it 
> is one of the better strengths that people can do so without permission from 
> anyone, as long as they use namespaces in a certain way to not conflict with 
> others. This is part of the distributed "DNA" of XMPP, and emphasizes that 
> the XSF is just one moving part in our community and not the end all and be 
> all of things XMPP.
> 
> However, I also strongly believe that using the term XEP implies that it is 
> part of the XSF XEP series, and that an XMPP extension in whatever format 
> only becomes a XEP when it is accepted as Experimental, becoming part of the 
> series and receiving a number.
> 
> I think XEP-0001 is clear on the above and the custom of calling things in 
> the inbox as proto-XEP affirms this.

I think I’ve already possibly caused more noise on this one than it was worth, 
but my concern wasn’t that the statement is ambiguous for people who Know 
What’s Up, but that an absolute novice to the ecosystem might see it as a 
statement that they can’t write their own extensions, and just move onwards 
without giving XMPP a second chance. It seems like a simple text tweak might be 
unecessary, but also not harmful.

I’ll drop this one now, smarter people than me can judge it.

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Kevin Smith]

> On 11 Jun 2021, at 21:12, Dave Cridland  wrote:
> 
> 
> 
> On Fri, 11 Jun 2021 at 17:10, Kevin Smith  > wrote:
> I’m just picking at replies here - as I said in the chatroom I think this is 
> a generally positive direction and want to thank the people involved.
> (I did make two suggestions there)
> 
> 
> For the record (and my notes), I'll paraphrase these here:
> 
> * "No person has any automatic right to join a chatroom, or write a XEP." in 
> §3 ought to be something else, since writing a XEP doesn't need the XSF's 
> permission as such.
> 
> I'm not sure what this can be, but I accept that writing private extensions 
> using the XEP format and publishing them independently might be considered 
> "writing a XEP", and that's not within the XSF's purview.

I think I suggested some text at the time that was something like “No person 
has any automatic right to have XEP submissions considered” or such. I’m just 
concerned (perhaps for no good reason) that that ‘write a XEP’ might confuse 
people wrt. their right (from our IPR policy) to modify XEPs etc. I believe I 
expressed that I thought tweaking this would be a benefit, but not crucial.

> 
> * There's limitations on what the XSF (via the Board) can sanction a member 
> for; in particular removal of any rights stipulated in the bylaws.
> 
> The ramifications of this one are really interesting. Is ejecting a member 
> from the members mailing list allowed? Probably, but that may mean they're 
> not notified about a meeting, which is a bylaw right (or a responsibility of 
> the XSF at least). Members can be removed, but with difficulty. I wouldn't 
> want this to be made any easier, either.

Squelching would presumably be allowed, but not removing their ability to see 
notices or XSF business.

> It may be as simple as noting that XSF Members, while held to a higher 
> standard as regards the Code of Conduct, have certain immunities with regards 
> to potential sanctions, and so members may have to take that into account 
> when voting them in.

That seems quite sensible.

>> On 11 Jun 2021, at 15:18, Dave Cridland > > wrote:
>> 
>> > The Conduct Team will always hand its recommendation on Sanctions or
>> > other Actions to the Board. The Board will discuss and vote on these
>> > "in camera" (ie, not in public and not minuted).
>> 
>> It seems like there's not much point having a conduct team if the board
>> also has to relitigate their decisions. I'd just allow the board to
>> delegate this authority fully (which presumably they could do anyways
>> and this document doesn't curtail board power?)
>> 
>> 
>> I was in two minds about this, so thanks for raising it.
>> 
>> I went for Board ratification of decisions mostly for the ease of managing 
>> the authority, but also in part because then the Conduct Team becomes an 
>> investigatory and deliberatory team instead of both judge and jury.
>> 
>> But you're right in that this might end up with Board relitigating the 
>> decisions rather than just providing the final go-ahead decision and acting 
>> as a blame deflector.
> 
> I think that if we were to find that the Board consistently disagrees with 
> decisions made by the Conduct Team, the Board would likely have to look at 
> who they’d put on the Conduct Team.
> 
> If the Board has to approve the Conduct Team’s decision by really looking at 
> it and considering if it’s reasonable, is that not basically going through 
> the appeals procedure pre-emptively?
> 
> 
> I don't think so.
> 
> Where there are valid appeals, this may mean the Conduct Team hasn't done its 
> job right in finding the facts, or it may mean that despite their best 
> efforts, there was information they were unaware of.



I think, from your response, that my point wasn’t clear. If the Board were to 
be required to do a full analysis of whether the Conduct Team’s decision was 
correct in the first place, there seems there'd be little point in having an 
appeals process of going to Board to check the Conduct Team’s decision - 
they’ll already have done so.


> I’m not sure I have a strong sensible opinion on this one, it seems 
> non-trivial.
> 
> Notwithstanding the above, it's not necessary for the Board to make the final 
> decision - I did it that way based on a virtual coin-flip, but fully 
> delegating the authority seems fair too.
> 
> Or indeed partially - we could involve Board when sanctions or public 
> statements are felt to be needed by the Conduct Team, but otherwise let them 
> get on with it and just report.
> 
> Honestly, I haven't even decided if I'm ambivalent on this point.

I think there’s an implied statement that actions are somehow more significant 
than non-actions, but I think that’s probably not true. Actions are a statement 
that the behaviour was unacceptable, non-actions are a statement that the 
behaviour (or resolution to it in the ‘girls’ example) is acceptable, which is 
probably just as 

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Ralph Meijer]

On June 11, 2021 10:12:31 PM GMT+02:00, Dave Cridland  wrote:
>On Fri, 11 Jun 2021 at 17:10, Kevin Smith  wrote:
>
>* "No person has any automatic right to join a chatroom, or write a XEP."
>in §3 ought to be something else, since writing a XEP doesn't need the
>XSF's permission as such.
>
>I'm not sure what this can be, but I accept that writing private extensions
>using the XEP format and publishing them independently might be considered
>"writing a XEP", and that's not within the XSF's purview.

I don't agree here. Hairsplitting below.

Yes, people are free to create XMPP extensions (lowercase), and I believe it is 
one of the better strengths that people can do so without permission from 
anyone, as long as they use namespaces in a certain way to not conflict with 
others. This is part of the distributed "DNA" of XMPP, and emphasizes that the 
XSF is just one moving part in our community and not the end all and be all of 
things XMPP.

However, I also strongly believe that using the term XEP implies that it is 
part of the XSF XEP series, and that an XMPP extension in whatever format only 
becomes a XEP when it is accepted as Experimental, becoming part of the series 
and receiving a number.

I think XEP-0001 is clear on the above and the custom of calling things in the 
inbox as proto-XEP affirms this.

-- 
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Dave Cridland]

On Fri, 11 Jun 2021 at 17:10, Kevin Smith  wrote:

> I’m just picking at replies here - as I said in the chatroom I think this
> is a generally positive direction and want to thank the people involved.
> (I did make two suggestions there)
>
>
For the record (and my notes), I'll paraphrase these here:

* "No person has any automatic right to join a chatroom, or write a XEP."
in §3 ought to be something else, since writing a XEP doesn't need the
XSF's permission as such.

I'm not sure what this can be, but I accept that writing private extensions
using the XEP format and publishing them independently might be considered
"writing a XEP", and that's not within the XSF's purview.

* There's limitations on what the XSF (via the Board) can sanction a member
for; in particular removal of any rights stipulated in the bylaws.

The ramifications of this one are really interesting. Is ejecting a member
from the members mailing list allowed? Probably, but that may mean they're
not notified about a meeting, which is a bylaw right (or a
responsibility of the XSF at least). Members can be removed, but with
difficulty. I wouldn't want this to be made any easier, either.

It may be as simple as noting that XSF Members, while held to a higher
standard as regards the Code of Conduct, have certain immunities with
regards to potential sanctions, and so members may have to take that into
account when voting them in.


> On 11 Jun 2021, at 15:18, Dave Cridland  wrote:
>
> > The Conduct Team will always hand its recommendation on Sanctions or
>> > other Actions to the Board. The Board will discuss and vote on these
>> > "in camera" (ie, not in public and not minuted).
>>
>> It seems like there's not much point having a conduct team if the board
>> also has to relitigate their decisions. I'd just allow the board to
>> delegate this authority fully (which presumably they could do anyways
>> and this document doesn't curtail board power?)
>>
>>
> I was in two minds about this, so thanks for raising it.
>
> I went for Board ratification of decisions mostly for the ease of managing
> the authority, but also in part because then the Conduct Team becomes an
> investigatory and deliberatory team instead of both judge and jury.
>
> But you're right in that this might end up with Board relitigating the
> decisions rather than just providing the final go-ahead decision and acting
> as a blame deflector.
>
>
> I think that if we were to find that the Board consistently disagrees with
> decisions made by the Conduct Team, the Board would likely have to look at
> who they’d put on the Conduct Team.
>
> If the Board has to approve the Conduct Team’s decision by really looking
> at it and considering if it’s reasonable, is that not basically going
> through the appeals procedure pre-emptively?
>
>
I don't think so.

Where there are valid appeals, this may mean the Conduct Team hasn't done
its job right in finding the facts, or it may mean that despite their best
efforts, there was information they were unaware of.

But equally, I don't think most cases will result in any appeal at all, and
frequently no actions.

As a real example, two (or three, depending how you count) FOSDEMs ago I
made a comment to Edwin, saying that I'd noticed - and I quote myself as
best as I can recall after two and a half years - that there seemed to be
"a much better proportion of girls in cybersecurity than elsewhere in our
industry". Edwin rightly pointed out that referring to professional women
as "girls" was more than a bit condescending, and I accepted that and
nothing more was said. (As Sam suggests, he did so quietly and calmly, and
didn't dox me on the mailing list, making it much less likely to put me on
the defensive and escalate the situation).

Under this Code of Conduct, Edwin (and perhaps also me) would drop an email
to the Conduct Team, more for them to keep a finger on the pulse than
anything else. Edwin would note that he called me out on it, and that I
took the criticism in the way he'd intended. I'd expect the Conduct Team to
do precisely nothing, maybe double check with me that I did now understand
how my comment could be perceived - but possibly just take Edwin's word for
it that I do.

And for the record, I do - while referring to "the girls" and "the boys" to
include adults is perfectly common idiom here, I do realise that in a
professional context, and particularly with non-native speakers (and for
all I know, non-UK speakers), it might well come across condescending,
whatever my intent. By avoiding that idiom, I make our community a little
more welcoming (see §2.1) for very little effort on my part.

But back to the point - what am I going to appeal? Am I going to complain
that they should remove me from the stand at FOSDEM? Am I going to say they
shouldn't have spoken to me (and if so, how are they going to un-speak to
me?).

I've tried to make the policy "scale down" to quick resolutions and
course-corrections like this, and I don't see any 

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Kevin Smith]

I’m just picking at replies here - as I said in the chatroom I think this is a 
generally positive direction and want to thank the people involved.
(I did make two suggestions there)

> On 11 Jun 2021, at 15:18, Dave Cridland  wrote:
> 
> > The Conduct Team will always hand its recommendation on Sanctions or
> > other Actions to the Board. The Board will discuss and vote on these
> > "in camera" (ie, not in public and not minuted).
> 
> It seems like there's not much point having a conduct team if the board
> also has to relitigate their decisions. I'd just allow the board to
> delegate this authority fully (which presumably they could do anyways
> and this document doesn't curtail board power?)
> 
> 
> I was in two minds about this, so thanks for raising it.
> 
> I went for Board ratification of decisions mostly for the ease of managing 
> the authority, but also in part because then the Conduct Team becomes an 
> investigatory and deliberatory team instead of both judge and jury.
> 
> But you're right in that this might end up with Board relitigating the 
> decisions rather than just providing the final go-ahead decision and acting 
> as a blame deflector.

I think that if we were to find that the Board consistently disagrees with 
decisions made by the Conduct Team, the Board would likely have to look at who 
they’d put on the Conduct Team.

If the Board has to approve the Conduct Team’s decision by really looking at it 
and considering if it’s reasonable, is that not basically going through the 
appeals procedure pre-emptively?

I’m not sure I have a strong sensible opinion on this one, it seems non-trivial.

/K___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Dave Cridland]

On Fri, 11 Jun 2021 at 13:19, Sam Whited  wrote:

> > Note also that this is not intended to mean that any XMPP developer's
> > behaviour will be scrutinised constantly - using, for example, racist
> > language in a talk about your XMPP project would be problematic here,
> > but using sexualised language in an unrelated setting is likely to be
> > irrelevant to this Code of Conduct.
>
> While I think it's fine to call out that we won't actively police
> behavior outside of XSF functions (which seems reasonable), I don't
> think that makes them irrelevant to the CoC. If we do hear about and
> verify some egregious behavior outside of the XSF we still may not want
> that person representing the XSF.
>
> If nothing else I'd remove "is likely to be irrelevant to this CoC" and
> put the decision in the hands of the working group.
>
>
There is a lot of history around this particular issue in other
organisations where the Code of Conduct has been applied unexpectedly to
activities outside its obvious remit, and to (what some believe) are
political ends. There are even cases where Codes of Conduct have been
changed in order to make this the case retroactively. I'm not going to go
into specifics of cases, but it's an area where I entirely understand that
people are concerned.

Now, yes, I think there are cases where behaviour in an unrelated setting
is likely to be an issue for us, but what I don't want to imply is that
just because using sexualised language in a Summit would be a serious
problem, that means you can't have a hobby writing erotic fiction. My point
is that behaviour is often contextual, and unless other people reasonably
think it reflects on us, we should keep out.

So if someone tweets something that - if said in our chatrooms, for example
- would be against our Code of Conduct, I would be very reticent to suggest
the Conduct Team should take any action beyond, at worst, reminding that
person that their tweet would be seen as exclusionary in our community. To
do otherwise risks becoming exclusionary ourselves, which is counter to the
whole point. But, as noted, if they were a Board member, say, that changes
the dynamic considerably.

That said, a lot of behaviour that's against the Code of Conduct is
actually flat-out illegal, ranging from hate speech to actual murder, and
that's a different matter - though jurisdictional differences apply of
course - I would assume that actual illegal behaviour does reflect on us.

As always, textual suggestions here are welcome.


> > please do call it out to that person at the time
>
> Should we define how this is done? I assume it means "gently mention
> that you don't believe this lives up to the CoC in the venue the
> behavior occurred in or in the chat" and not "post in every single
> forum you can find about it and include the users home phone number
> and email".
>
>
The latter is itself against the CoC, so hopefully not. But yes, my intent
here was that - if people feel able to do so - to calmly and gently express
their concerns, privately or otherwise in response - and not escalate
things into a vicious row.


> > Who you report it to depends on who was involved in the incident.
>
> Can this be clarified? I would assume we'd always want to go to the
> contact team unless it was a member of the contact team (then maybe the
> board, or if they're the same, the rest of the board).
>
>
Yes, Jonas also pointed out this wasn't obvious, though you're spot on in
terms of the reasoning here.

That said, I don't know if we want to ignore complaints (and I don't like
that word) if they have been reported incorrectly. My concern in this is
that I don't want a level of formality to dissuade people from reporting
incidents because they're minor, or they feel more intimidated by the
process than the incident itself.


> > The Conduct Team will always hand its recommendation on Sanctions or
> > other Actions to the Board. The Board will discuss and vote on these
> > "in camera" (ie, not in public and not minuted).
>
> It seems like there's not much point having a conduct team if the board
> also has to relitigate their decisions. I'd just allow the board to
> delegate this authority fully (which presumably they could do anyways
> and this document doesn't curtail board power?)
>
>
I was in two minds about this, so thanks for raising it.

I went for Board ratification of decisions mostly for the ease of managing
the authority, but also in part because then the Conduct Team becomes an
investigatory and deliberatory team instead of both judge and jury.

But you're right in that this might end up with Board relitigating the
decisions rather than just providing the final go-ahead decision and acting
as a blame deflector.

I am very open to opinions here.


> > In high profile cases, the result will be announced publicly.
>
> I'd also just say "At the conduct teams discretion" instead of limiting
> it to "high profile" cases which seems vague and confusing.
>
>
Yes, there's a 

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Ralph Meijer]

Thanks for your comments. I'll let Dave respond in detail, except on this:

On 11/06/2021 14.19, Sam Whited wrote:

Also a general nit picky note for the editor: all the various hyphens
should be converted to em-dashes and "a XEP" should be "an XEP" (I
thought? Maybe that's not true in all dialects but I didn't think this
is one that would change).

No. The term "XEP" is normally pronounced "zepp" [6].

[6] 


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Sam Whited]

> Note also that this is not intended to mean that any XMPP developer's
> behaviour will be scrutinised constantly - using, for example, racist
> language in a talk about your XMPP project would be problematic here,
> but using sexualised language in an unrelated setting is likely to be
> irrelevant to this Code of Conduct.

While I think it's fine to call out that we won't actively police
behavior outside of XSF functions (which seems reasonable), I don't
think that makes them irrelevant to the CoC. If we do hear about and
verify some egregious behavior outside of the XSF we still may not want
that person representing the XSF.

If nothing else I'd remove "is likely to be irrelevant to this CoC" and
put the decision in the hands of the working group.

> please do call it out to that person at the time

Should we define how this is done? I assume it means "gently mention
that you don't believe this lives up to the CoC in the venue the
behavior occurred in or in the chat" and not "post in every single
forum you can find about it and include the users home phone number
and email".

> Who you report it to depends on who was involved in the incident.

Can this be clarified? I would assume we'd always want to go to the
contact team unless it was a member of the contact team (then maybe the
board, or if they're the same, the rest of the board).

> The Conduct Team will always hand its recommendation on Sanctions or
> other Actions to the Board. The Board will discuss and vote on these
> "in camera" (ie, not in public and not minuted).

It seems like there's not much point having a conduct team if the board
also has to relitigate their decisions. I'd just allow the board to
delegate this authority fully (which presumably they could do anyways
and this document doesn't curtail board power?)

> In high profile cases, the result will be announced publicly.

I'd also just say "At the conduct teams discretion" instead of limiting
it to "high profile" cases which seems vague and confusing.

> While the sanctions described herein are, by their nature,
> exclusionary, and much of the behaviour discussed is negative, the
> intent is the opposite - we want to maximize inclusion, and promote
> positive behaviours.

This is great, but feels out of place at the end of a section
about appeals.

Also a general nit picky note for the editor: all the various hyphens
should be converted to em-dashes and "a XEP" should be "an XEP" (I
thought? Maybe that's not true in all dialects but I didn't think this
is one that would change).

Overall this is a great start, thank you!

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Policy XEPS [was: NEW: XEP-0458 (Community Code of Conduct)]

[Sam Whited]

I tend to agree with this in general (XEPs are hard to format and write,
hard to read, etc.) but also we can barely keep editors around and doing
their full job as is so having two things for them to maintain (or
finding another body to maintain the new documents) seems impractical.
I'd love to hear suggestions for how it could be made easier though.

—Sam

On Fri, Jun 11, 2021, at 08:03, Andrew Nenakhov wrote:
> A boy with a hammer sees everything as a nail. A member of XSF has a
> clear procedure, so he sees everything as a XEP.
>
> However, imagine a fresh developer, who wants to create a messaging
> app, and has these available sets of documents:
>
> https://xmpp.org/extensions/ https://matrix.org/docs/spec/
> https://docs.rocket.chat/
>
> Which platform would he select to create an app? Why he is least
> likely to choose XMPP?
>
>
> пт, 11 июн. 2021 г. в 16:10, Ralph Meijer :
> > Hi Andrew,
> >
> > Thank you for your feedback.
> >
> > When the XSF (then JSF) started publishing XEPs they were known as
> > Jabber Enhancement Proposals. We modeled this after other
> > organizations, in particular the well-known PEP series of the Python
> > Software Foundation. It is explicitly the intent to include both
> > procedural and protocol standards documents in this series. This is
> > why there are different *types* of XEPs, or *tracks* if you will.
> > You can read up on this in XEP-0001.
> >
> > The fact that the expanded name is now XMPP Extension Protocol
> > doesn't change that fact. Whether that change was a wise choice is
> > debatable, and maybe indeed we should have used XMPP Enhancement
> > Proposal or XSF Enhancement Proposal or some such. I remember there
> > was a discussion on this way back when, but I haven't taken the time
> > to look it up in our archives.
> >
> > Including procedural documents into standards series like this is a
> > very common practice. Examples include the PSF mentioned above,
> > numerous Apache Software Foundation procects, and the IETF. Doing it
> > this way provides us with a clear framework for developing
> > procedures and putting them in force. It doesn't preclude to
> > possibility to (also) present the output of such proposals in other
> > places, like a dedicated page on the XSF website.
> >
> > If you have suggestions on how to improve our processes, we welcome
> > your constructive input. We then have clear ways to consider your
> > suggestions, including proposals to include cookie recipes.
> >
> > --
> > Cheers,
> >
> > ralphm
> >
> >
> > On 11/06/2021 10.40, Andrew Nenakhov wrote:
> > > Yet another irrelevant document masquerading as a protocol
> > > extension. I suggest stop using XEPs as an unsorted pile of
> > > various texts, or else you'll soon have cookie recipes there. If
> > > you want some place for a CoC, just put in on a website in
> > > 'community' section next to 'membership' page.
> > >
> > >
> > > чт, 10 июн. 2021 г. в 21:32, Jonas Schäfer  > > >:
> > >
> > > Version 0.1.0 of XEP-0458 (Community Code of Conduct) has been
> > > released.
> > >
> > > Abstract: This document describes the XMPP Standard
> > > Foundation's Code of Conduct
> > >
> > > Changelog: Accept as Experimental after unanimous approval by
> > > Board of the ProtoXEP draft for discussion within the
> > > community. (XEP Editor (jsc))
> > >
> > > URL: https://xmpp.org/extensions/xep-0458.html
> > > 
> > >
> > > Note: The information in the XEP list at
> > >   https://xmpp.org/extensions/
> > >    is updated by a separate
> > >   automated process and may be stale at the time this
> > >   email is sent. The XEP documents linked herein are up-to-
> > >   date.
> > > ___
> > > Standards mailing list Info:
> > > https://mail.jabber.org/mailman/listinfo/standards
> > > 
> > > Unsubscribe: standards-unsubscr...@xmpp.org  > > unsubscr...@xmpp.org>
> > > ___
> > >
> > >
> > >
> > > --
> > > Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com
> > > 
> > >
> > > ___
> > > Standards mailing list Info:
> > > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe:
> > > standards-unsubscr...@xmpp.org
> > > ___
> > >
> >
> > ___
> > Standards mailing list Info:
> > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards-
> > unsubscr...@xmpp.org
> > ___
>
>
> --
> Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com
> 
> 

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Andrew Nenakhov]

A boy with a hammer sees everything as a nail. A member of XSF has a clear
procedure, so he sees everything as a XEP.

However, imagine a fresh developer, who wants to create a messaging app,
and has these available sets of documents:

https://xmpp.org/extensions/
https://matrix.org/docs/spec/
https://docs.rocket.chat/

Which platform would he select to create an app? Why he is least likely to
choose XMPP?


пт, 11 июн. 2021 г. в 16:10, Ralph Meijer :

> Hi Andrew,
>
> Thank you for your feedback.
>
> When the XSF (then JSF) started publishing XEPs they were known as
> Jabber Enhancement Proposals. We modeled this after other organizations,
> in particular the well-known PEP series of the Python Software
> Foundation. It is explicitly the intent to include both procedural and
> protocol standards documents in this series. This is why there are
> different *types* of XEPs, or *tracks* if you will. You can read up on
> this in XEP-0001.
>
> The fact that the expanded name is now XMPP Extension Protocol doesn't
> change that fact. Whether that change was a wise choice is debatable,
> and maybe indeed we should have used XMPP Enhancement Proposal or XSF
> Enhancement Proposal or some such. I remember there was a discussion on
> this way back when, but I haven't taken the time to look it up in our
> archives.
>
> Including procedural documents into standards series like this is a very
> common practice. Examples include the PSF mentioned above, numerous
> Apache Software Foundation procects, and the IETF. Doing it this way
> provides us with a clear framework for developing procedures and putting
> them in force. It doesn't preclude to possibility to (also) present the
> output of such proposals in other places, like a dedicated page on the
> XSF website.
>
> If you have suggestions on how to improve our processes, we welcome your
> constructive input. We then have clear ways to consider your
> suggestions, including proposals to include cookie recipes.
>
> --
> Cheers,
>
> ralphm
>
>
> On 11/06/2021 10.40, Andrew Nenakhov wrote:
> > Yet another irrelevant document masquerading as a protocol extension. I
> > suggest stop using XEPs as an unsorted pile of various texts, or else
> > you'll soon have cookie recipes there.
> > If you want some place for a CoC, just put in on a website in
> > 'community' section next to 'membership' page.
> >
> >
> > чт, 10 июн. 2021 г. в 21:32, Jonas Schäfer  > >:
> >
> > Version 0.1.0 of XEP-0458 (Community Code of Conduct) has been
> > released.
> >
> > Abstract:
> > This document describes the XMPP Standard Foundation's Code of
> Conduct
> >
> > Changelog:
> > Accept as Experimental after unanimous approval by Board of the
> > ProtoXEP draft for discussion within the community. (XEP Editor
> (jsc))
> >
> > URL: https://xmpp.org/extensions/xep-0458.html
> > 
> >
> > Note: The information in the XEP list at
> > https://xmpp.org/extensions/ 
> > is updated by a separate automated process and may be stale at the
> > time this email is sent. The XEP documents linked herein are up-to-
> > date.
> > ___
> > Standards mailing list
> > Info: https://mail.jabber.org/mailman/listinfo/standards
> > 
> > Unsubscribe: standards-unsubscr...@xmpp.org
> > 
> > ___
> >
> >
> >
> > --
> > Andrew Nenakhov
> > CEO, redsolution, OÜ
> > https://redsolution.com 
> >
> > ___
> > Standards mailing list
> > Info: https://mail.jabber.org/mailman/listinfo/standards
> > Unsubscribe: standards-unsubscr...@xmpp.org
> > ___
> >
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>


-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Ralph Meijer]

Hi Andrew,

Thank you for your feedback.

When the XSF (then JSF) started publishing XEPs they were known as 
Jabber Enhancement Proposals. We modeled this after other organizations, 
in particular the well-known PEP series of the Python Software 
Foundation. It is explicitly the intent to include both procedural and 
protocol standards documents in this series. This is why there are 
different *types* of XEPs, or *tracks* if you will. You can read up on 
this in XEP-0001.


The fact that the expanded name is now XMPP Extension Protocol doesn't 
change that fact. Whether that change was a wise choice is debatable, 
and maybe indeed we should have used XMPP Enhancement Proposal or XSF 
Enhancement Proposal or some such. I remember there was a discussion on 
this way back when, but I haven't taken the time to look it up in our 
archives.


Including procedural documents into standards series like this is a very 
common practice. Examples include the PSF mentioned above, numerous 
Apache Software Foundation procects, and the IETF. Doing it this way 
provides us with a clear framework for developing procedures and putting 
them in force. It doesn't preclude to possibility to (also) present the 
output of such proposals in other places, like a dedicated page on the 
XSF website.


If you have suggestions on how to improve our processes, we welcome your 
constructive input. We then have clear ways to consider your 
suggestions, including proposals to include cookie recipes.


--
Cheers,

ralphm


On 11/06/2021 10.40, Andrew Nenakhov wrote:
Yet another irrelevant document masquerading as a protocol extension. I 
suggest stop using XEPs as an unsorted pile of various texts, or else 
you'll soon have cookie recipes there.
If you want some place for a CoC, just put in on a website in 
'community' section next to 'membership' page.



чт, 10 июн. 2021 г. в 21:32, Jonas Schäfer >:


Version 0.1.0 of XEP-0458 (Community Code of Conduct) has been
released.

Abstract:
This document describes the XMPP Standard Foundation's Code of Conduct

Changelog:
Accept as Experimental after unanimous approval by Board of the
ProtoXEP draft for discussion within the community. (XEP Editor (jsc))

URL: https://xmpp.org/extensions/xep-0458.html


Note: The information in the XEP list at
https://xmpp.org/extensions/ 
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards

Unsubscribe: standards-unsubscr...@xmpp.org

___



--
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Dave Cridland]

On Fri, 11 Jun 2021 at 09:41, Andrew Nenakhov <
andrew.nenak...@redsolution.com> wrote:

> Yet another irrelevant document masquerading as a protocol extension. I
> suggest stop using XEPs as an unsorted pile of various texts, or else
> you'll soon have cookie recipes there.
> If you want some place for a CoC, just put in on a website in 'community'
> section next to 'membership' page.
>

It's definitely not intending to masquerade as a protocol extension - there
are lots of policy documents in the XEP series, by intent, and this is a
"Procedural" XEP, not a Standards Track document. If we need to make that
clearer, let's do so.

Board did discuss whether to put it on the website only, or a XEP, or both.

Making it a XEP (even if we *also* put it onto the website in a more
traditional format) means we can discuss it as a community while it remains
Experimental, and we have clear procedures on how it gets updated,
approved, and made an Active policy.

As for its relevance, I rather hope it is and remains irrelevant - really
the only reason for it to be relevant is if we have a problem. Cookies seem
a much better outcome.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Andrew Nenakhov]

Yet another irrelevant document masquerading as a protocol extension. I
suggest stop using XEPs as an unsorted pile of various texts, or else
you'll soon have cookie recipes there.
If you want some place for a CoC, just put in on a website in 'community'
section next to 'membership' page.


чт, 10 июн. 2021 г. в 21:32, Jonas Schäfer :

> Version 0.1.0 of XEP-0458 (Community Code of Conduct) has been
> released.
>
> Abstract:
> This document describes the XMPP Standard Foundation's Code of Conduct
>
> Changelog:
> Accept as Experimental after unanimous approval by Board of the
> ProtoXEP draft for discussion within the community. (XEP Editor (jsc))
>
> URL: https://xmpp.org/extensions/xep-0458.html
>
> Note: The information in the XEP list at https://xmpp.org/extensions/
> is updated by a separate automated process and may be stale at the
> time this email is sent. The XEP documents linked herein are up-to-
> date.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>


-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___