Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)
Updates: On Fri, 11 Jun 2021 at 15:18, Dave Cridland wrote: > > > 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. > > I've made the example about explicit language more explicit, as with the example above; I think that now reads that the exemplar case (of erotic fiction writing) is likely to be irrelevant, rather than reading like a general comment. > > 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. > Clarified this, and added some rationale. > > >> > 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. > > Added some text to clarify these thoughts. > > 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
Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)
Updates: On Fri, 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've reworded this slightly to use "the XEP series" as an example of "XSF documents" > * 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. > > Done something like this. > 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
Re: [Standards] XEP-0227 update
Thanks Matt, a couple of comments: On not namespace bumping: 227 already said you had to cope with unexpected elements, so simply including the new elements in their new namespaces seems ok to me. (Although this may generate warnings. *shrug*) PEP: Do you mean PEP as in 163, or full pubsub-on-a-JID? I assume the latter - is it worth being explicit? What needs to happen if you can’t process the config fully on import (because of features the exporting server supports and you don’t). But otherwise looks good, thanks. /K > On 2 Jun 2021, at 16:59, Matthew Wild wrote: > > Hi folks, > > This somewhat forgotten XEP used to be the way to migrate data between > XMPP services. Unfortunately it didn't keep up with the times, and > many servers gained tools for importing directly from the native > formats of other servers (Prosody has an ejabberd importer, ejabberd > has a Prosody importer). > > Even if it never again becomes the standard format for server software > migrations (XML is not an ideal format when you're dealing with > massive amounts of data), as part of the XMPP account portability > project[1] I want to once again bring XEP-0227 up to date with what > data commonly constitutes an XMPP account. > > I've prepared an update that adds some of the missing features: > > - SCRAM hashes (it previously recommended inclusion of plaintext passwords) > - PEP nodes (configuration and items) > - Message archives > > I'd appreciate feedback, and also I'd be curious of any wishlist items > that anyone else may have. > > The draft PR is at: https://github.com/xsf/xeps/pull/1064 and a > rendered version is available at > https://matthewwild.co.uk/uploads/xeps/xep-0227.html > > Regards, > Matthew > > [1]: https://docs.modernxmpp.org/projects/portability/ > ___ > 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] Proposed XMPP Extension: Moved 2.0
This is looking good; thanks! I've started an implementation here (currently only supports sending a moved request from the client side): https://github.com/mellium/xmpp/tree/moved2/moved After work I'll add the server side so that I can write some round trip test cases and then move on to what other contacts need to do with the subscription requests and let you know if I run into anything odd. Things will look a lot cleaner once I get a pubsub implementation done too, which I really need to get on at some point. —Sam On Fri, Jun 25, 2021, at 09:05, Jonas Schäfer wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Moved 2.0 Abstract: This specification details a way for a user > to notify their contacts about an account move. > > URL: https://xmpp.org/extensions/inbox/moved2.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > ___ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > unsubscr...@xmpp.org > ___ > -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Moved 2.0
On Fri, 25 Jun 2021 at 14:34, Andrew Nenakhov wrote: > > What happens if a user has several connected clients that support this xep? I should add a note about this to the design considerations, indeed. The summary is, as far as I see, "nothing bad". If N clients are concurrently connected, they may race to verify the moved notification (resulting in N requests to the migrating user's PEP node), and they may all accept the subscription request if verification succeeds. XMPP is already designed to handle this okay - approving a subscription request multiple times will have no adverse effects. I think it's ideal if the server handles it where possible, but the multi-client situation should work just fine. Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Moved 2.0
What happens if a user has several connected clients that support this xep? On the broader subject, I think that any xep that is oriented at doing anything on clientside should have a mandatory section dealing with multi-device use cases. On Fri, 25 Jun 2021, 16:07 Jonas Schäfer, wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Moved 2.0 > Abstract: > This specification details a way for a user to notify their contacts > about an account move. > > URL: https://xmpp.org/extensions/inbox/moved2.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > ___ > 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] XEP-0227 update
Hi list,
On Mittwoch, 23. Juni 2021 20:05:20 CEST Matthew Wild wrote:
> On Wed, 23 Jun 2021, 17:21 Guus der Kinderen,
>
> wrote:
> > Should we consider introducing a change to the namespace as used in the
> > portable data, to more explicitly handle the changes in format? I'm aware
> > that you mainly introduced new elements, and the one attribute that you
> > dropped ('password') is defined as a 'should' - but still: the output is
> > significantly different.
>
> I'm not sure I agree that it's *significantly* different. As you say, it's
> mostly adding new stuff. So let's see...
>
> If we use existing namespace for old elements:
>
> [… snip …]
>
> My thoughts: the goal of XEP-0227 is about maximizing interoperability
> between servers. Bumping the namespace on elements that have not changed
> their format reduces interoperability.
I agree; as long as the new elements are in a new namespace (and they are), I
think we’re good.
> > Given the nature of the protocol, it is not unthinkable that data exported
> > by an implementation following the older XEP version gets imported by one
> > of a newer version, and vice versa - perhaps with plenty of time between
> > import and export (eg: backup restores).
Important argument which supports Matthews approach IMO.
kind regards,
Jonas
signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
[Standards] Proposed XMPP Extension: Moved 2.0
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Moved 2.0 Abstract: This specification details a way for a user to notify their contacts about an account move. URL: https://xmpp.org/extensions/inbox/moved2.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
