XSF Discussion - 2017-03-01

Ge0rG, :D

(re 21:44:26 Ge0rG> "The "S" in IoT stands for Security." just has become my quote of the year.)

huh... is there a board meeting?

Never ending board meeting, yes

oh right

so is the gavel continuously banging? I don't hear it

(I keep meaning to ask RE the never ending board meeting jokes: is there a subject or something set that mcabber doesn't show? IDGI)

/topic

SamWhited, the topic

> The room subject is now: Board Meeting | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

Huh, I don't see that; maybe mcabber never updates the subject

I see

> XSF discussion room | Logs:…

Ha

oh no, I had this discussion with someone; that's the title of the bookmark (set by Mcabber or Conversations or whatever I added it with) which I guess was the title at the time; mcabber shows whatever the bookmark contains

These jokes are lost on me :)

The subject that is the topic, but not the description?

That's ... sorta sensible I guess

SamWhited: why should it set the subject as the name?

Showing the bookmark title seems sensible, not sure about setting the bookmark title to the subject (but I'm also not sure what I created this bookmark with in the first place, so no idea where that came from)

Easy XMPP clients will show the disco#info name. I'm sure they will.

Ge0rG: ¯\_(ツ)_/¯ I think it's probably Conversations that does this, so ask there

Unfortunately, the name of this MUC is "xsf".

maybe we should have a name, a pretty name, a description, a subject, and a bookmark name. *pokerface*

Hi all

hi

SamWhited: so the first item would be the "ugly name"?

Ge0rG: yup, the never-changing single-word-no-spaces-no-special-chars name (no idea why, just 'cause). Maybe it's the local part of the JID.

SamWhited: see you in the SgmLxqI+A0tOdwPfVXNdd1H4 chat room.

holy crap.

Google can't even federate their own chat apps.

1. Welcome

the board meeting goes into its third week

Who's there, any agenda items?

*wave*

Present

I assume nyco, too.

yep

Do we have MattJ?

https://trello.com/b/Dn6IQOu0/board-meetings

As a note upfront, I've been swamped with work and haven't kept tabs on anything XMPP for the last two weeks.

One item for me is IEEE

anything else?

Discourse, Board priorities

OK

2. IEEE

We

What happened to a decision on software listed on the site?

That's old business

've received a message from William Miller on IEEE IoT efforts and their desire to incorporate our IoT specs in more of their work.

But they're not our specs. The XEPs they are referring to are expired and defunct

Asking to move them to Active

I don't want to go into the details in this meeting.

I think we should ask Council to provide guidance on how to move forward, and possibly appoint a liason to the IEEE for this work.

+1

third party people implementing defunct XEPs and pushing them as standards to other standards groups is a situation we need council to get on top of

With my council hat on (though I can't speak for everyone else of course) I think this is a matter for the IoT SIG to decide; if they want to improve the current XEPs, they will be reopened, if not, they can create new ones (possibly while working with the IEEE group)

But I do agree that if we *don't* want to improve the existing ones (and I think the consensus at the summit was that we don't), then we should definitely be careful to try and stop people from implementing them if there are known issues or we're not going to push them as official standards.

I'm not sure if they really need these specs per se, but rather just XMPP-based ones.

Hey, sorry, another meeting overran

I'd like someone from board to reach out to Mr Miller re: XSF membership, they should have at least one person from their firm if they're implementing

With my Council hat on, the IoT SIG is subject to Council, so if Board asks the Council to Do Something, then I imagine Council will ask the IoT SIG and make a decision based on that input. But a Liaison as a first step seems sensible.

And even though there is an IoT SIG, this is exactly why I wanted a Council person to be heading the IoT SIG

he appears to be in Washington DC given his phone number. I'd be happy to reach out to him, have coffee with him, etc

Sure thing.

SamWhited: can council at least work with Rikard and the IoT SIG to come up with a strategy?

I don't think "we're throwing away the current specs" is a sensible approach to start interacting with IEEE

ralphm: That sounds sensible; I didn't mean to suggest that we shouldn't be involved. I'll add an agenda item for next week

https://trello.com/c/5SHoH80M

Done; comments can go there if you want us to discuss anything in particular next week.

Who wants to formulate a response to William to kick off interaction with the IEEE?

I'd like that to not wait until next week

Is that not Arc's coffee meeting?

Maybe yes

im not going to meet with him about IEEE as much as to understand what his firm is doing and explain what XSF is, encourage membership, etc

leaving council issues aside, the part of the email that stuck out is he's speak from outside the XSF. and we really want implementors in the XSF.

I'd have thought that's a reasonable first response.

arc: sure, we can to the actual IEEE liasoning or whatever later.

I think council does need to come up with a strategy for the iot stuff besides this

arc, Agreed.

Yes, so that's part of what SamWhited's agenda item

Any other comments on this?

None here, sounds like a plan

3. Discourse

Yep, sounds good to me

nyco?

yes, the thread on the mailing list

also: Je pense

RE Discourse: If this is seriously being considered, I would like to have a(nother?) public comment period so that I can complain about what a terrible experience it is a lot. I won't waste time in the council meeting with it though.

oops

https://trello.com/c/qcPd55vA/260-use-discourse-on-discuss-xmpp-org

s/council/board/

nyco, Donc, je suis?

more or less ;-)

I haven't read the discussion in great detail, but don't feel we have problem that needs resolving here

on a technical level

we indeed have issues, that are worth admitting

Discourse is a great solution

I'm not so hot on Discourse too, and agree with the sentiment that we should aim for an XMPP based solution

I haven't used it, so can't really comment

adding a new discussion media is a long term burden to the XSF that shouldn't be done lightly

we discussed quite extensively at the Summit around modernism we lack this, like very badly also, we should lower the barrier of entry

I'm happy for people to play with this, but I'd hate to use this as a main thing for any of our current mailing lists before gaining significant experience.

ralphm, mailing list is still there

Maybe we could trial it for some discussion venues, but not others?

MattJ, IoT WG

nyco: but not the mailman archives, right?

MattJ, also maybe if we wake the CommTeam back from the dead?

nyco, No, thanks. I'd rather it was used for jdev, or something else that's not a SIG.

ralphm, better archives, with real search that brings actual results, and tagging

Worth answering (but not necessarily right now): If we trial it for a WG, can we be sure that we can get to the archives later or move back to a mailing list if we decide not to use it long term?

I a trial can be done without any changes in the current setup, as an add-on, I'm ok

(or anywhere really, but especially if it's an official function of the XSF like a WG)

if

nyco: I'm sure everything is nicer, better, awesomer. I'd like to not have an disruption to the current setup.

any

ralphm, agree

Flow: I know, but I also don't want IoT to not be on an island. Especially not IoT.

mailman 2 is an island

we're all on it... :'(

How about setting up an entirely new discussion venue?

dwd: hm?

That's kinda what I meant

dwd, yeah on Slack!

Create, say, a UX "list", but make it Discourse (or something) instead.

Oh. In that case, something like SCAM would be appropriate

Some measurement of success would be to ensure not just that the new system was used, but also that existing XSF members participated in it

Right

to quote the Zen of Python, "Now is better than never, Although never is often better than *right* now."

or not

We don't want to throw out our existing community in an attempt to appear shiny to other groups of people

ity uccess, right?

I want to reraise the issue that Discourse is not in any way XMPP based.

I'd wager most of our existing community is just fine with the current setup (except searchable archives would be nice)

this was a concern raised on the thread.

Look at Discourse as you would look at an upgrade from Mailman2 to Mailman3

So the question becomes, who is doing it?

arc, for that matter, mailman is in no way XMPP based :)

Nobody is throwing out the existing community by using Discourse

arc, so it mailman

is

mailman is simply email. It doesn't use fancy realtime features more suitable to XMPP

Flow, that sounds great - though I've heard conflicting opinions on whether that's true (I can't say myself as I haven't used it)

We're in overtime.

we will attract non-members, which is good(tm)

So, again, who's taking this on, and do what?

ralphm: I already volunteered

I've been using it for the past few weeks since this came up; I resubscribed to the rust-users list (which I unsubscribed from before a few weeks after they moved to Discourse) to see if things had changed. I turned on mailing list mode, and used it from my client. It was not a plesant experience.

let's just start to install it for IoT SIG

SamWhited, concrete issues would be helpful to know (but not necessarily right here right now)

I'm -1 on implementing this. I don't think a strong enough argument has been made for its need, and it could add a signifigant future burden to migration in the future

the current experience is less than pleasant

stuck in the past

we need that wave of modernism

well contemporarism

I think I outlined them on the list last time, but if this discussion starts up I'll go through and write out the individual pain points again.

I'm -1 on implementing this for an existing group, and specifically for IoT

they want it

They also wanted Skype for Business

Let's (someone?) set up a new venue for starters, that's an actual first step

so you're saying what they want is irrelevant?

nyco: I don't disagree with you that this would be good, the arguments against Discourse are on the merits of Discourse itself, not against innovative solutions

nyco: no, I'm saying that we as an organisation are responsible for it working properly

Then after it's up, we can discuss moving venues to it at a later date

Not irrelevant, but also not the top concern; they may want it, but the rest of the XSF has to read this stuff too, and having archives will be important later. There are just more considerations than "they want it and it's shiny"

and I think IoT has other, bigger issues

nyco: I am not joining the IoT SIG exactly because of their choices of non-XMPP mediums for discussion.

arc: We use Jitsi Meet since months

I have no idea what work is currently being done in the IoT SIG, nor how to find out

I didn't know it was still active

exactly, MattJ

Discourse will make that visible... ;-)

Mmmmhm

The visibility of Mailman2 mailing lists

Can you all pretend that I asked "Why?" to every statement in here?

I'm sure you can easily follow what happened in iot@ by reading the mailman2 archive

, not.

Why would Discourse make that any easier to follow?

nyco: it wouldn't make it more visible. The last message before today was January 8

ralphm, yes, it would, that's one of the points

https://mail.jabber.org/pipermail/iot/

SamWhited: No subpages per months, as starter.

I can follow my e-mail client archives just fine, and I agree with MattJ

Didn't the IETF have a nicer browser for mailman archives, if this is the issue?

Oh, I see, you're assuming the web interface. Yah, that's pretty bad, however, Discourse's non-web interface is pretty bad, so we're just trading one bad interface for another.

MattJ: That's one of the issues

i.e. I'm sure existing work has been done in this area

ralphm, so can you with Discourse

nyco: my point is that I don't believe non-movement in IoT is going to be solved by new technology for discussion

ralphm, true, but non-movement on our discussion means are killing

ralphm: As Guus what he thought about moving Openfire to github years ago. And read what he now writes in the ignite realtime blog

Can't we just ask politely to add the list of affected xeps into the subject when posting to our lists?

There are prettier web frontends to mailing lists around, like Nabble, http://lua.2524044.n2.nabble.com/

So it's doable

That's different; GitHub is a central community with network effect. A Discourse instance isn't.

I think the correct way forward on this is to have a discussion session for future-comms where multiple solutions can be discussed. Not simply a "I think we should move to X solution".

Zash, still ugly and old style, frightening

arc: form?

SamWhited, to achieve network effect thanks to its value, then do lower the barrier of entry

nyco: However, for many it reduces value

mailing list or a MUC chat

No, correct way to move forward is to do something. But within the XSF you will always find someone who is opposing that is why nothing happens ever.

SamWhited, I'm saying network value, Metcalfe's Law

Flow, agree, non-action hurts so badly

It was similar with the new xmpp.org homepage

don't give me the problem of resources

Simon also got yelled at for trying to move forward

the non-members, the external communities than we need so badly, will welcome that move

Flow: ok, if you can set up Discourse in such a way that we *also* keep having archives in Mailman as we have now, you have my blessing.

Is that possible?

I'm ok with that, too.

why not disrupt?

are you doing nothing, to keep the comfort of a few?

ralphm: My idea was roughly to start with a test setup, and then switch one ML after another ot discourse and then eventually make mailman2 read-only.

nyco, You know that disruption isn't a means to an end?

dwd, ;-)

Flow: ok, but can you run in hybrid mode?

Flow: enough concerns have been raised to that, its not going to happen

We can always try to find someone to migrate the old posts to discourse if we want

arc: Concerns like?

arc, enough concerns have been raised to stay that way

this isn't one person objecting. several people have concerns over the proposal

ralphm: hybrid mode?

arc, several people are all for it

if we want actual numbers, we can call for a survey

something as fundamental as our communication medium affects everyone. for that, there should be rough consensus to change.

This isn't about numbers or a vote, it's about the people who are for it assuming that the burden of proof to show that this is a good idea is on everyone else and not addressing the valid concerns brought up by others on the list.

yeah, a members vote would be great thing to get a feeling what the XSF members think

(although I'm not against gathering numbers or data, of course, why not? Sounds nice.)

arc, the state of our current infra is affecting everyone, including the ones who don't join, because...

SamWhited: I think I've addressed most, if not all, concerns raised on the ML thread

Flow, I think running up a discourse instance with a real - but not critical - workload would be a sensible step.

Flow, We could also then try other options (Movim, maybe?).

Flow: what I said before: if you can run it such that messages go to both Discourse and Mailman's archive, then please go ahead

Same with other platforms

dwd, why Movim?

nyco, Why not?

I want to stop this discussion as part of this meeting now.

dwd, because mailing list?

ok

Flow: If I'm not mistaken, what you want is a more modern communications medium. Your chosen solution to that is Discourse. But other solutions could meet your needs. That is why we should discuss this in a new-comms meeting

arc, I have not seen any equivalent, please enlighten us

please stop

ralphm is right, we're way over time.

ralphm: Well I suppose you could do that with the help of your MTA. But I'm not sure if it's a good idea. What would be the advantage?

so, we end the meeting? or address the last agenda item?

Flow: I want to either have a setup that doesn't involve current workgroups so we can test, evaluate, *or* something that doesn't affect the current infra

(so that Discourse would just be an alternative interface)

I propose we put an end to that meeting

Seconded

nyco: I'm still at the office with a 2 hour commute ahead. I'm going to end this meeting

the neverending meeting may have a one-week pause

I'm happy for people to keep discussing this afterwards

ok then thanks all! it was a great discussion!

4. Date of next

+1W

+1

5. Close

Thanks all!

Thanks

thx, see yah

Thanks ralph

Thanks ralphm,

Flow: Yah, sorry, went back and looked, I never did send my concerns about it, so obviously you didn't reply to them :) will do that next time this comes up on the mailing list or whenever arc's comms meeting happens.

XSF Discussion | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

It's interesting how our experience divergates. Discourse has major traction within the open-source forum software. I find it very enjoyable on mobile and on my workstation, and I really like that I can use it just like mailman

Flow: please don't feel discouraged. I am really curious about new things, but worried about inertia and continuity.

MattJ: https://mailarchive.ietf.org/arch/

Zash, I know. Source doesn't appear to be available?

Can't find it

I'm pretty sure the disagreement is going to be starkly divided down the line of how it's used: If you use the web/mobile apps, it's very nice. If you use it as a mailing list, it's terrible.

Well I already decreased my investment in XSF stuff, because it is nearly impossible to change something. Discourse on the other hand is something that I really think the XSF needs most right now. So it's the only thing I currently pursue

SamWhited: Did they run a version which included https://github.com/discourse/discourse/commit/74b6fe8739d86dc2284707e8507ac732420a1b8c ?

I still don't understand what benefit it gives us that a search box and a slightly nicer interface wouldn't

MattJ: https://trac.tools.ietf.org/tools/ietfdb/browser/ maaybe?

It's not only the search box

Just hat you can tag threads with the xep numbers is a huge win IMHO

Flow: That was one of the changes between last time and this time when I tried it, they did, and it was *much* better. But still a pretty terrible experience.

Looking forward to your elaboration what made it so terrible on members@ thread

(or at least, I assume that was one of the changes; that would explain a lot of the improvements around replying)

Zash, well done

Our Mailing List, especially standards@, is a huge pile of valuable information, yet it's not really accessible

It sends a bunch of garbage HTML, doesn't use conventions in the plain text version (and leaks some form of [bbcode] or something into the plain text), it sends different "topics" from different email addresses so it's hard to write filters (though admittedly, this sounds like it could be how the rust-users and rust-internal instances were configured), off the top of my head. There were others; replies were broken somehow still, but I don't recall now, I'd have to go look.

Flow, Discourse won't fix that unless it can import the archives (can it?)

Sure you can. You just probably need to write the code doing so

But I think 1. that there are many mailman2 instances upgrading to discourse, so it's only a matter of time until someone does write that code

What's wrong with this IETF thing? It looks nice and would fix the accessibility problem (assuming we can get the source from them, which I'm sure we could)

Flow: again, I think decoupling the specific solution you've chosen to champion from the needs to be addresed is a good first step

and 2. we can always do the import later

What arc said

yeah, i'm already sold on discourse for various reasons

so I don't need to decouple that

You do if you want to convince anyone else

true, but not everyone

IMHO Discourse is without alternatives and the best horse to bet on

that's not a great position to bring to a discussion like this.

why not? I try to back my claims with arguments. And I'm happy if you convince me of an different alternative

Flow: Take this: https://tools.ietf.org/html/rfc6778 s/IETF/XSF/ and call it a day ;)

I haven't made a decision yet. What you're feeling as push-back is against the "right now" aspect to your drive. XSF has used MUC and email forever. The board, council, and most WGs use these.

The first part of the push-back is the expediency, people have said that the case hasn't been made to why these things have to change right now.

Well to be fair, if not "right now" then it'll be never, based on experience :)

"Now is better than never, although never is often better than *right* now"

that comes from the python-dev list. very (very) often people comes through saying that X or Y or Z is mission critical, that Python is driving away potential new users because it doesn't have a feature, or a change to the C-API is absolutely necessary or they couldn't use Python, etc

in almost every case decisions made "right now" are regretted.

Maybe someone (don't really care who, but it probably shouldn't be someone who's completely against Discourse like me, or completely for it like Flow) should evaluate several options and report back instead of us just making it an argument about "discourse or nothing". Other options have been thrown out, but the gist of the argument has mostly been about moving to discourse, not about improving in general.

MattJ is right, we need to act on it or it'll be forgotten. So Flow and nyco have ruffled feathers, people are activated, lets sit down like engineers and sort out what we want to do

I have questions as to MIX - in 2 years when we're all using MIX instead of MUC, will it be possible to merge our chat conversations with mailing list conversations in a meaningful way

The timeline may be of a lesser importance here

Merging slow, long form communications with quick, short form comms is probably not very easy in non-technical ways.

im thinking more in terms of archives

Ha

https://trac.tools.ietf.org/tools/ietfdb/wiki/ProjectSetup#CheckingouttheSourceCode

Zash: what is this?

Modern

arc: I don't know. Unless I've gotten lost, it may be the source code to https://mailarchive.ietf.org/arch/

I think this is just the archive stuff: https://trac.tools.ietf.org/tools/ietfdb/browser/mailarch/trunk

(if we can find the source, we should try it; this is very nice)

its an archive front-end to mailman?

Although if you want to post from a web interface, which might be one of the discours peoples desires, it's hard to tell, it won't help

RabbitMQ dependency... doh

lol

what is it using rabbitmq for?

They seem to have some independent processes, maybe for syncing with the mailman archive and indexing

holy crap. its march 1st. I can code again.

Go slow, maybe stick with just Lua for a while :)

i have a month of ideas for libexi

you should see the pages of rubics cube algorithms ive written out

but the month off was good i think. my vocabulary has returned, i should see the doctor again before i start again though

get a new baseline to see what the month break resulted in

i'll just read today.

dwd, ny?

Oh! That's where that went.

So I *entirely* lost that while typing, and had no idea it was actually sent.

heh

Zash: I think this is the mailing list stuff the IETF uses that we were looking for earlier: https://code.google.com/archive/p/ml-archive/

It has some similarly named resources anyways…

> 404. That's an error. > The project ml-archive was not found.

SamWhited: I found some svn repo with some Python stuff in it.

I just clicked through to the sources and now it says there isn't any… something weird is happening.

Yay Google

/lastlog recent links I've pasted here

Zash: Oh, I thought the one you posted Mat or somebody said was just a database or something

but yah, looks like it… nevermind, already found.

SamWhited: I don't know for sure what I found, I've stayed too far from python web dev to know how to get whatever it was running.

That's a smart plan.

Worked with a homebrewed Python + MongoDB web framework at my last job.

Email, sigh.

The thing in XMPP where the same connection is used for incoming and outgoing traffic is pretty nice.

Zash: like in s2s?

Ge0rG: {xep 288}

Ge0rG: XEP-0288: Bidirectional Server-to-Server Connections (Standards Track, Draft, 2016-10-17) See: https://xmpp.org/extensions/xep-0288.html

Ge0rG: I mean the feature where I don't have to type my password 3 times to send an email.

Or have 3 different passwords.

I haven't entered my password for email in the last three years. It's stored in a plaintext config file

I haven't figured out how to save my password in mutt yet.

So I get the pleasure of typing a password for IMAP, a password for GPG and a password for submission.