XSF Discussion - 2014-02-28

Just realised I completely missed the members meeting last night! Sorry everyone!

no problem ;-)

Glad to see I haven't been kicked out (yet)!

:)

Ash: You voted by proxy. That's more than far too many of our members managed.

Kev: :-/

Or, at least, ISTR you did. If you didn't, shame on you :P

I did, Kev. Yes I did!

Kev: publicly? Half-kidding.

ralphm: Not sure what the question is.

the shaming

Public shaming, mouhahaa

like with vote tallies for council, really

We explicitly note who did and didn't turn up for Council and Board meetings, because this stuff is important when voting on people.

Kev: my point

There's a follow-up.

The problem with publicly shaming XSF members is that there're two possible outcomes:

1) Those members who aren't contributing anything don't pass re-votes.

2) Yet more people who blindly vote Yes on every issue, irrespective of whether they're sufficiently informed to do so.

I think 2 can't be helped anyway. And maybe it really gives an incentive.

I don't know to be honest

just thinking aloud

Welcome to Democracy

I do wonder if we should switch to something like range voting.

range voting?

So you'd mark each [re]applicant from 1-5. Makes people think more.

Also, range voting defeats Arrow's Theorum.

(Which basically says that all voting is unfair)

I'm not sure how that would work. Each member application is independent, unlike Council/Board.

I think possibly we should re-raise the 'abstain' issue from a while back.

On the assumption that it's possible that many members vote 'yes' because they don't feel sufficiently informed to vote at all, and thus voting 'no' would be bad.

(One member did express this problem to me, which is why I brought up the issue months ago)

At the time I decided that abstaining was pretty much the same as voting No, but I think that if that person's vote is then not counted as part of the sum for testing majority, it'd be fine.

Little as I like the thought of fiddling with our bylaws.

How would you propose improving the informedness of members in this respect? Could lead to failed votes because people abstain, thus possibly not reaching quorum for (re)applicants voted on.

I think that a member deliberately casting an abstention counts towards quorum.

Is how you solve the second problem.

So in that case we could have a theoretical applicant X that gets 40 abstains, one yes, zero no and is thus voted in.

And for the first - well, you either have to make sure everyone's informed (which is a huge time sink - to be able to sensibly vote for XSF members you have to follow pretty much all the mailing lists and more), or let people say they're not well enough informed with an abstention.

intosi: Yes. This doesn't strike me as a problem.

Ok. That would make Abstain more of a 'Do not care either way'

Or, at least, far less of a problem than the current situation, where people are essentially casting Yes in place of abstaining.

Yes, that's what an abstention is.

Kev: that's a fair point.

What's the problem we're trying to solve? Having too many members? Or voting for Council / Board?

If you wanted to vote against them, you'd vote No.

K

Fair point

simon: Current members see a new membership application and aren't sure if the person is really coming from nowhere without contributing (should be No), or has been contributing heavily and relevantly on a list they don't follow.

simon: So they vote Yes.

simon: So anyone applying to the XSF is guaranteed to be accepted.

Do we need to limit members?

Yes.

Why?

Because members vote on Council/Board.

To be on the voting list you need to fill out a wiki page which suggests some interest in XMPP. And we want to reject these people (who probably won't be bothered to vote anyway) becasue?

Also apologies for not getting my proxy vote in, had planned some time to get it done but dwd can talk the hind legs off a donkey (never got that one) :)

simon: Because Council is critically important to the XSF's mission. If you have a system that encourages a disengaged membership, you move away from informed decisions on selecting a Council, and instead move to random selection.

Lloyd: if every member that didn't vote in time would feel the need to send appologies, we would have less of a discussion..

(And Board similarly has the power to screw everything up, so similar arguments apply)

Kev: And the fear is that a disengaged member will just vote randomly?

I disengaged member cannot, by definition, make an informed decision on voting.

s/I/A/

Are we seeing evidence of this?

One of the members asked a while back if I could raise the issue of abstentions because they were forced to vote by the bylaws, weren't sufficiently engaged to be able to do so properly, and so felt they had to vote Yes on everyone's member applications.

So yes.

Right - that makes sense.

I suspect if you were to go down the members list, you would manage to find some people who have never contributed in a meaningful way to the XSF's goals, yet are members.

You can take voting attendance as some sort of evidence of members not doing their job, if you like.

I'll accept a handful of members missing single votes because Dave talks too much.

yes. Although to become a member shows some interested in XMPP and perhaps we should be reflecting on what we can do to better rope them in and turn them into an army of XMPP supporters. I don't know the answer to this, but do think that we should find a better way of mobilising someone that goes through the effort of creating a page about themselves on the XMPP website.

But when around a third of your membershp (I didn't count) is missing, that's not screaming to me "I'm taking my role in the XSF seriously".

I think that's a dodgy basis.

I think becoming a member shows some interest in being a member.

The barrier to entry for voting is very very low. If people aren't even doing this, I don't see how we can hope to mobilise them into action.

There is also a group of people who /do/ vote and are interested and could be motivated into doing more, I'm sure.

See the group of people stepping up to the Editors team, for example.

XSF membership was never very clear to me and when I asked was explained to me about 4 years ago as "Simon you should become a member becasue it looks good and you don't have to do very much" (or something along those lines).

So maybe, no vote, no apology + 3 strikes == out? Can reapply immediately?

Lloyd: Well, that's pretty much what we already have.

kev: is it enforced?

I've learnt what membership entails. But I'm not sure it's clearly laid out anywhere or if it is, it's not publicised well.

Lloyd: Not always.

simon: Right, I think many membership applications are similarly motivated purely by "Hey, this makes me look good" arguments.

That's not an interest in XMPP, it's an interest in being an XSF member, and these aren't the same thing.

(Of course, there's the argument of whether just having an interest in XMPP is enough to justify being a member, but that's a must less clear-cut debate)

Do we have any ideas of how do other communities handle this?

The IETF has somewhat involved rules around eligibility for things, and does away with having a wide membership that votes on it.

I like our simple model better, I just think it could do with slight tweaking.

I wonder if section 2.6 may help for members that don't attend or vote at meetings. Has that ever been used?

It has.

But that doesn't address the current issue :)

On another note, I just noticed this clause: "An applicant for membership may not be admitted if, at the time of application or consideration, fifteen percent (15%) of the Members of the Corporation are employed by or represent the same corporation or organization as that corporation or organization which employs the applicant or is represented by the applicant."

Is there a page that explains the role and requirements of members?

I think we're getting close to that limit :O

simon: http://xmpp.org/about-xmpp/xsf/xsf-bylaws/

Kev: maybe that's the problem - there's bylaws and then there's day-to-day expectations that need to be clearer and not buried in legalese.

as much as I enjoy reading bylaws...

Maybe our membership application form should have a static block of "I understand my obligations..." that everyone has to paste.

But: I'd have thought that all members should probably have read the bylaws at least once.

This may be overly optimistic, though.

I think you are assuming that everyone is a Kev. Nice as that would be...

So yes. Having some "This is what being a member means" page that it's impossible for an applicant to not have read, would probably go some way towards this.

That's a great idea Kev

It's not unreasonable to expect members of a standards org to read the actual standards governing that same org. The by laws are part of that.

Then the applicants can copy the text into their applications.

Reading the by-laws is somewhat like reading the instruction manual - I'd admit that I only did it after becoming a member (but had asked an existing member about responsiblities, etc)

simon: This needs more than just going on the website, I think. It needs entwining into the application process.

kev: +1

I think this is supplemental to, rather than obviating the need for, the abstention thing, though :)

Kev: yes - a "I've read <url> and agree to uphold my duties as a member" type blurb

Kev - can I put you down to write a "What is expected of members" page for the new website?

Not in the near term.

we'd need this in about 8-12 weeks time.

Ask me again in a few weeks then.

I have no capacity at all for volunteering for additional stuff right now.

Hmm. I may have restabilised my DSL sufficient to join in the debate now it's ended.

Well done.

So... The nice thing about range voting vs abstaining is that if it's set to, say, 1-5, then '3' can be made equivalent to an absention. For things like Council/Board, though, it gets more interesting, because things like "split votes" cease to apply - that is, voting for someone makes them always more likely to get in, and never less.

I don't think this is really equivalent.

Heard back from the decentralise folk, they are taking proposals for another couple of days then will start deciding on talks/workshops (cc simon & fippo)

That 3 will still pull the average in.

Lloyd - also heard back from them. Same story.

I don't have the cycles to run the maths, though.

lloyd/simon: smae here ;-)

I think thats a social problem which we cannot solve. I have been in many orgs, institutions or local (hobby) clubs. Always the same problem. A small amount of people is doing the most work, while others only enjoy their benefits.

"Can't solve" isn't the same as "Can't improve"

Kev: I agree

dwd: any objections against me submitting the starttls-dialback thing that has been lying around in my customxeps github thingie since last november?

fippo, Oh. Can I give it a once-over first?

fippo, I wanted to add some stuff.

dwd: git pull and then update :-)

Basically instead of just looking at the impact of TLS on dialback, I wanted to expand it to cover DNSSEC as well.

that would be excellent. i think this will make the whole DNA discussion alot more clear

We are february end, when will be the date of the meeting? http://wiki.xmpp.org/web/Membership_Applications_Q1_2014

Yesterday

??

I have not received announcement...

http://logs.xmpp.org/xsf/140227/#20:02:33

and the date is not on the wiki page

...

Neustradamus: http://mail.jabber.org/pipermail/members/2014-February/007674.html

but I have informed that there is a problem with the ML...

Well, problem with your mail provider, in fact.

Neustradamus: switch to hosting your own mail while we try to resolve various mailing list issue. You then get to decide whether or not something is unwanted or spam, instead of Microsoft. I know that's a sucky answer, but it really works wonders for these kinds of issues.

Also, the meeting is in the XSF calendar

I got spam from Google today. Much fun.

Neustradamus: I can add other mail addresses for you to mailman if you want

Just reminding anyone who can make the London XMPP meetup on Tuesday to sign up. Need numbers for pizza and beer (the things that matter) Meetup link broken but Lanyrd here: http://lanyrd.com/2014/xmppuk/

Can you count me without me signing up? :)

There's some names on the wiki too right?

Lauta: do me a favour, and include at least one pizza with meat, but without mushroom ;)

00hey kev, I just noticed a new face on isodes managment team ;-)

fippo: Because you like to just check that page for fun? :)

fippo, VP in Presence :) he'll be present everywhere soon

He's not VP in omnipresence, Tobias.

I should probably register for the WG.

intosi, not yet

Laura: I would also appreciate if you could count me in without me needing to sign up somewhere

Zash: Oh you're coming over? Fab.

kev: well, because i had to unsub an email address that will be gone actually

Kev: Yup

Zash: will do, thanks for letting me know

Laura: You caught me in that too?

Also - seems there's 50 minutes left to register for the IETF thingy. I should get on with that.

Have now

Diolch.

Maybe I should too

And the country codes link is broken \o/

fippo, I've done a quick edit or two. If I knew how to do a pull request in github I would do one now.

fippo, Ah-ha, I figured it out now.

I've been using Github recently for some non-XMPP code (shock!), and I really like just about everything about it other than the pull request model.

It's just as well no future employer of mine is likely to spot that I don't understand pull requests, isn't it?

Kev: what is it about pull requests that you don't like?

I don't like the merge model in Git.

Rebase all the way :)

Oh, I mostly like merges, but only for real merging. Rebasing makes more sense in most cases.

The big problem with merging is that it breaks bisect.

And bisect is lovely.

rebasing is wrong imo and I don't like it one bit

Lloyd: You have every right to be wrong.

I was always fascinated by the Monotone suggestion for branching at the point a bug is introduced, fixing the bug on the branch, and then merging on release branches. So the VCS becomes your bug tracker. (Branch not meregd at this point? Bug exists at this point.)

:)

(I actually like the /concept/ of merges, in that it preserves information that is lost in a rebase. But they're unpleasant to manage, and break bisect. So pragmatism wins over principle in this case)

Lloyd, If it's one small change, rebase. Developing a lengthy feature, I'd go for a merge, since it'll preserve the history. Rebasing would work, but means you either have weird history that doesn't reflect the changes actually made, or else lose the history entirely and squash.

fippo, Ta.

Working on a gsoc blog for Philipp

laura: thanks!

fippo, Laura - What's this for? I thought we didn't apply for GSoC? I is confuddled.

I assume to say how happy we are that other XMPP-related projects are participating.

kev: exactly

and pointing people to jitsi and instantbird

Right, OK. TAB.

dwd: shout out about 'we may not be sponsoring, but projects still include xmpp' etc

I spent too long typing. What they said.

Kev: if you think that bisect doesn't work with merges, I think you are doing it wrong

Yup. As I said, TAB. (Or rather, TaB, really)

ralphm: There are some (quite specific) cases where it doesn't.

fippo: all done

Where the breakage occurs in one branch, but the other branch contains build fixes (e.g. for new versions of dependencies or whatever).

(Which sounds contrived, until you actually suffer through it)

Kev: this isn't really a property of branches, but the way you are looking for breaking changes, IMO

arguably, though, git doesn't actually *have* branches, even though they are called that

it does have branch heads

unlike, say, mercurial, where git-style branches are called 'bookmarks'

Right. I think the Git model for branches is great.

Kev: You have every right to be wrong.

:)

Indeed. I'll take advantage of it some day.

laura: thanks. i'll see about tweeting it, my #webrtc audience might be larger (-:

The problem I have with rebases is that people generally tend to write horrible commit messages while working on a branch. Merging gives a (second) change of writing a good one, that also has the general overview.

ralphm: I don't think that's a problem with rebases, really, though, is it?

It's a problem with terrible commit messages, and I can appreciate that.

ralphm, Actually, rebasing gives the oppoertunity too. git rebase -i is your friend.

ralphm, You even get to squash commits together for the pointless commits you did.

does our mediawiki instance allow fancy tables like that one: http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers

dwd, Kev: as long as those branches haven't been shared, I'm fine with that. In fact I like mercurial queues, which also really are mostly equivalent to sqashed rebased branches

Lance: what's the state of the push XEP?

Ge0rG: https://github.com/legastero/customxeps/blob/gh-pages/extensions/push.md

0/names

err....

Lance: using "her" re the user is sexist! :P

then I will change it, so long as you would have likewise complained had I used "his" :P

just pushed a fixed link for the turn/rest draft to xep.ent btw

Lance, We should use a sexless robot for all our examples.

fippo, IIRC, xep.ent is the realm of the Editors.

dwd: right, so we sort out this procedure now :-)

Lance: my favorite is "their"... I'll submit a patch request

Ge0rG: heh, that's the state i was in when I wrote it :)

Lance: the iq stanzas are missing the from/to addresses

and ids

Lance: at least the initial register should be sent to the client backend service, if I read it right

ah, yes

while the enable IQ should be sent to the XMPP server

correct

this distinction is important enough to be added.

shall I add it to my diff?

certainly

any language improvements welcomed

it feels very mealy-mouthed at the moment

lots of similarly named terms with nuanced differences

Lance: is it a good idea to provide a specific service-value in the register iq result? like "push-023.client.example"?

specific as in "different from the generic jid the iq is sent to"

possibly, in showing that it is possible

I assume the service-value is meant to allow backend scalability?

or rather to not limit implementation choices

it could be a component that uses a resource to identify users, for example

Lance: the configure example is referencing no push service for the iq-get, but a given service for iq-set. is that generic or specific configuration?

Lance: what about allowing multiple client-push-services?

Lance: https://github.com/legastero/customxeps/pull/1

+1 for the github web interface. it allows submitting changes even under the influence of alcohol

Ge0rG: again, placeholder. the idea is to be able to set a generic, blanket configuration and also be able to modify a config for a particular service

I am really excited about this stuff

Ge0rG: yes, multiple client-push-services are allowed (but i may be misunderstanding what you meant there)

Lance: I am talking about how a client can get the general config, and the per-backend config, and how it can set them

ah, right. i updated the document to hopefully clarify that

http://www.ggmania.com/pics//14/feb/evo/evo.jpg

yay! I contributed to a proto-XEP!

dwd: I know I'm pestering you way too much, but do you have a feeling if/when you can bring the yaxim-MUC project into a state where someone else could look at it?

ge0rg: if he promised, it will take less than five years ;-)

fippo: this is a sensible upper bound

Ge0rG, For you, less than four years.

Ge0rG, More seriously, I'll find some time next week to run through a bunch more rebase steps.

dwd: that's great. Next week is perfectly right, I'm having some days off...