XSF Discussion - 2019-11-22

I was not able to be here for yesterday's meeting due to my work, much to my regret. I would like to congratulate new Council&Board! Hope they give the best of them! :) Also thank you very much Alex!

On that note: Zash Daniel pep. I have created separate issues for each of you to provide a bio for our website. Be fast, or run the risk of me making one up for you 😆

(I didn't miss anyone on that list, did I?)

MattJ If you haven't thought about that yet: could you make sure that the relevant mailing lists (board@ is one, unsure if we have others) and github permissions are updated?

Yes, I have some time this afternoon, I'll do it then

thanks!

pep. can you confirm your Trello username? I'll add that to the Trello board for Board

While I'm in mailman I'll see to removing the footer from standards@ unless someone has a sensible objection

Guus: you might be able to retrieve Daniel's bio from git history

Ge0rG I already suggested that in the issue

unsure if Daniel wants to see it updated.

Ah, perfect

but I provided the old text for him

oh, wikipedia lists people too, I believe

updated Wikipedia

... anything else?

Unrelated, but trying to benefit from MattJ's window of opportunity: This issue seems worthy of a redirect of sorts https://github.com/xsf/xmpp.org/issues/651

I'll see :)

feels like this election would have benefited from condorcet voting, something like https://civs.cs.cornell.edu/

although it wouldn't automtically help with ties, I think it would have helped people to express their opinion and especially from preventing them from strategic voting (cast less than 5 votes), which may be one reason why we have so many 'No' votes

flow, what?

I thought No just means "did not explicitly vote for them"

seems to be confirmed by yes+no always being equal to 39

(which is the number of folks who voted) ✏

I was also under the impression that you only can say "yes" or "no", and not None

Ge0rG, you can "abstain" for one or more of your votes

which probably counts as one less "yes"

(and one more "no")

jonas’, that

you are not forced to cast 5 yes votes

but if "abstain" means "no", what's the difference?

Ge0rG, when you abstain, you discard one of your "yes" votes

aaah!

flow, ah, indeed, not everyone used their five votes

so you could just vote "no" for everybody

specifically, we have 12 abstainations(?!) for Board

Ge0rG, correct

and even 21 for Council

now I wonder whether I’m doing this wrong

39*5 - sum(yes votes for body)?

Counting is fun.

flow, irrespective of that, yes, I also thought that we should maybe use a different system for the body elections

I’m not sure if a process geared towards finding the (one) best choice of a set of choices is correct for a thing where we elect the top N choices

voting is hard

I suggest you make your case on the mailinglist, outlining benefits over the current process.

I just voted in the Jenkins election and they use for example civs.cs.cornell.edu

ah, they support the Schulze method

and MAM :-X

(sorry)

I am not saying that we should use that particular system from cornell, but condorcet voting sure seems desirable

Is it just me, or is every system that we usually only tangentially need, infinitely complex when looked at?

It's just you and the other guy

Phew.

Who's the other guy?

Yeah I suggested ranked voting *before* we actually voted

And I'd be fine switching to something like that. Probably something new board can decide on

FTR, I have pondered this for a while and this is not in response to current results. More in response to the difficulty of casting votes though.

That said I don't see the problem with not giving away all five yes votes. If you only think four people can do the job

(yes I brought this up when we were talking about ties)

Daniel, I don't think the rationale for casting less than five votes is not that people believe that only <5 people can do the job, but that you really want those 3 people in council

Guus: have you updated mailing lists for board & council?

Or should I take care of that? Not sure if I have the keys to them ;-)

Alex I have no access. If you can, please! If you can't either, MattJ will have a look later today.

I agree the 'no' counts are not really proper.

"flow> feels like this election would have benefited from condorcet voting", I'm also in favor of Ranked-choice voting fwiw.

Atm there's no way to distinguish between no and absent

ralphm: Not 'proper' in what sense?

Not optimal, or actually improper by our bylaws?

Kev, in the current system there's no difference between "I don't want that person" and "I don't know"

(no / blank)

I think that's consistent with the bylaws at the moment.

Sure, that doesn't excuse it

Well, it does excuse the voting system, yes.

That doesn't excuse the fact that we're not looking for something better

The voting system does what the bylaws require of it. It's the bylaws that we want to change for a different approach, not just memberbot.

And yes, the current approach is daft, given the joint requirements of 5 people, and each having a majority vote.

I tried to explain Alex yesterday why I think the voting was not conducted in compliance with bylaws. He didn't agree with my assessment on bylaws compliance but he did agree that the voting system breaks when you start to have significantly more than 5 candidates, so imo we definitely should change it before next election

Third, the individuals elected shall be those receiving the highest percentage of votes cast, up to the limit set by the Members and with the proviso that no individual receiving less than a majority of votes cast shall be elected.

larma: Thanks for bringing it up here

larma: Yes, that's the daftness.

This section of the bylways can be an issue when we have a large pool of applicants

Yes.

Kev: I mean that we only vote 'yes' for candidates. Not 'no'.

Kev: so I'd display it differently, not change the outcome.

I would be willing to change it for the next elections

Actually, I take back my previous assessment. The bylaws continue to function, it's the memberbot that's not right.

The bylaws don't say that an individual is only allowed to vote 'yes' to the maximum number of people on Board/Council.

If you remove that restriction from memberbot, the system continues to function with a large pool.

That is true, we could totally have a range voting system.

You don't need range voting for it to work.

Just an unlimited number of 'Yes' votes.

With choices like 0 and 1, or even -1, 0, 1

Then 'pick the ones with the most votes, with not less than half' works.

I would personally like to have the option of explicitly expressing my disapproval of a candidate.

Although I admit that range voting might make it better.

Kev: how do you define less than half?

I think there's two questions. 1) What would make the current system non-broken (and I think it's a memberbot change, not a bylaws change) 2) what would the most appropriate system be.

Alex: if you have to vote -1, 0, or 1 for each candidate, less than half is the tally going below 0.

Alex: Under the current system, it's half the number of members voting.

Is there any record of member not voting btw? Alex. I'm looking at §2.6

It is my interpretation of the bylaws that I must be able to vote on each candidate or decide to not vote (abstain) from the vote of each candidate

We have indeed expelled people for not voting thrice in a row. But I think that was a long time ago.

pep., yes, some where removed in the past for not voting. I don't like this rule either. Its a lot of admin work with little value for me. Because they can just get voted in again the next quarter, and this happened before

I don't mind this rule. It asks for a minimum of contribution, which is really not much

The idea here was that voting for Council, Board is just about the only obligation Members have, and if you can't even be bothered to do that three times in a row, maybe you should not be a member.

However, for that to work, it needs to be made visible that people did indeed get removed, so that in such next elections, voters can weigh that in their choices.

(voting for Council, Board, *and Members*)

> Because they can just get voted in again the next quarter We should have a "blame list" then, so that people are aware that they were removed for that reason.

What ralphm said 😀

Well, I think it is sufficient to notify the Members mailing list.

I don't think we should maintain a naughty list.

Also, as I said, it has been a while since this happened.

Maybe not a naughty list

But a list of people who voted would make sense, alongside with the results, in small print or sth :)

Meeting minutes include a list of those present, so that should suffice.

(it includes people that voted by proxy)

ah ok

E.g. see https://wiki.xmpp.org/web/Meeting-Minutes-2019-11-21

Just for my understanding. Does anyone want to contest the current results, or are we just discussing possible improvements for future Council, Board elections?

If the former, please let me know, so I can look into it.

ralphm, ok these minutes are enough to me (the list of people). And personally I'm speaking about improvements for the next elections.

board and council election only? or are there also concerns for our quarterly membership votes?

next voting is starting soon

Is now a good time to do a switcharoo with the xmpp.org Prosody?

always

I don't see a reason to contest the results. I brought up this issue in private to Alex after election to not mess with this election, but Alex told that without any decision from members being taken, he does not plan to change the procedure (I hope that summarizes it correctly). (3.13) "Second, the Members shall vote on the candidates standing for election in accordance with Section 3.9 of these Bylaws." (3.9) "Each current Member of the Corporation (other than Emeritus Members) shall be entitled to one (1) vote on each matter submitted to a vote at a meeting of the Members". -> This is what makes me assume one should be able to vote on each candidate not just a set of up to 5 candidates. Also if one votes on each candidate, each candidate becomes a matter so it should be possible to abstain from voting for each candidate. And Alex, this only affects board/council elections, I think membership votes are perfectly fine (it's clear that every member is one matter to vote on).

Well I could also see a different voting system for members, someone might still want to say no explicitely

You already choose yes or no for each member application

(do I? I had my mind mixed up in council/board stuff..)

Ahem

I think the main issue is that the memberbot does not give the full flexibility of voting. But legally it is not required to, because Alex as a proxy can legally only accept whatever he wants and also he can legally completely ignore your memberbot wishes and instead vote something else for you.

No

hello world

If the Membership would like to change how memberbot works for Board, Council elections, they can take a vote on this, and then Alex will happily comply.

And of course someone needs to change the code.

Yes, I am also happy to use some other services like CIVS if we think they are a better solution for us. Or Webforms or whatever we come up with

I personally would rather prefer to get rid of memberbot for voting and instead a) have people vote during the meeting as it is intended b) have people pick any proxy to vote for them during the meeting if they cannot attend. This can be any other member that is present during the meeting, we don't need to bother Alex with that. Our member meetings are basically useless because they cannot be used for what they are intended (you cannot bring up things for discussion or vote during the meeting, but have to bring up every matter to vote on before the memberbot started). It shouldn't be the default to vote by proxy, it should be the exception for when people are not able to make it to the members meeting (which only happens one time a year and is announced way in advance, so most should be able to make it even in different timezones). Member meetings should be where members meet (and not only 10% of them) Maybe we should even have the annual members meeting during the XSF Summit so that many members are already at the same physical location?

Needing to bring up things for voting way in advance is a good thing

Zash, I agree, but it still should be possible to do so in the meeting. Also the exact thing to vote on could be the result of a discussion in the meeting

larma: I don't any of this as a problem

I don't see

only a small percentage of the members attend the summit. Members are distrubuted all over the world, and also are busy in their day jobs. I do not expect them all to join the meeting. This is also why we have proxy voting

Alex, there are different ways to do proxy voting

larma: I agree with Zash here. It would be *very* good to plan ahead if you need to bring something up with the membership. Also, if needed, we can have additional meetings for topics during the year.

Alex, "small percentage", more than attend the member meetings right now

ralphm, while I agree that bringing matters early is good, I don't like that the current implementation prevents bringing anything at all while memberbot is started. (Maybe not "at all", but it's impractical)

Also, we don't need the annual meeting to bring up topics. This is why we have a members mailinglist, and this room, and why our board meetings are open for all, etc.

pep. I have not yet seen a case where this has been a problem, and I prefer addressing problems after we've actually identified them.

Or rather, actually encountered them.

We do have five membership votes each year. It would be easy to add things to vote on into the next one.

And to discuss them in advance on members@

ya, this is wat we have done in the past. At max it takes 3 month to get a change approved and into a vote. 3 month should not be an issue

3 months is a bit long tbh :/

come on

isn't it?

what thing needs changing that runs into this

I've followed a bunch of discussions in here lately, and I feel people are in search for problems where there aren't any.

It will depend on the issue for sure, but once there is some kind of consensus on list I don't see why 3 months is required. If somebody has an issue they can reply to the thread before a vote is decided

Issues of the sort you need to get through a member vote should not be rushed

This takes up a lot of time, without a clear benefit. We don't have to strife for perfection, just because we can.

Also I don't see a point in attaching votes to regular meetings, as mentioned above it's not necessary

Well, I'd certainly don't see a reason to have *more* meetings, especially for the hypothetical cases we seem to be discussing.

Let's first have an actual problem?

> much room rooms

Alex, may I suggest to also put the list of members who did *not* vote into the meeting minutes? That would increase transparency and allow easier checking for a three-times not voted streak. This information is already publicly available, just not in a single place

and I assume memberbot has that list already

flow: which problem are we solving?

ralphm, make it easier for everyone to determine if the rule is followed

right now I have to get a list of the members at the time (from the website, out of the git, not sure if this is accurate), then the list of the members who voted from the minutes and create the list of members who did not vote

that I have to do for the last three times, and see if a name/jid appears all three times

> ralphm, make it easier for everyone to determine if the rule is followed

Is it because you think we have missed expelling people?

ralphm, no, I just like transparency and verify things, not to blame anyone, mistakes happens

and this seems like a low hanging fruit to increase the XSF's tranparency

as the list probably exists in memberbot already, it should be easy to add it to the meeting minutes

and it's also not leaking any data, as the data to construct the list exists publicly already

Transparency is great. I also think there is a) underestimation on what fixing such hanging fruit means in terms of work, b) a lot of actual work that that volunteer time could actually be put to use for. ✏

flow, in order to do that we would more data in the memberlist which we maintain in the website repo. Jids would have to be added. People have multiple jids, and sometimes vote from difefrent ids

surely the memberbot has a list of jids allowed to vote, and definelty a list of jids who voted, so creating the complement should be trivial

Alex: i dint want that my JID is public on the web

Alex, so memberbot does currently not run with the complete list of member JIDs?

and this is where the transparency stops ;-)

ade` transpiranyc cuz any random kek can get my jid out of the web

Alex: my words

I would assumed that there is a single memberlist including one jid per member acting as truth somewhere, which is used as input for the memberbot

flow, no, memberbot does not have the capability to compile this list. You can find memberbots code here: https://github.com/legastero/memberbot

flow: my point is that the XSF doesn't need to be perfect, IMHO. The information is out there, but maybe not in an optimal form. If you really care about it, write a script to compile the information in a way you think is better.

I'd much rather focus on XMPP itself, than get multiple people bogged down to solve cosmetic issues in our procedures. ✏

ralphm: i count that Jabber is 1A for communications

ralphm, 👍

For the record, I'm agreeing with ralphm largely. If we're not suffering from serious ill effects, we should consider limiting the amount of effort that goes into changing/optimizing processes.

ralphm, well I don't intent to add extra work on other people, but if someone motiviated to put effort into this, why not make it better?

flow: because no one asked for improvement

may be its ok how it is now

get some other topic flow

Open source development is largely about first finding consensus how to approach, and then finding someone to implement it, not about having other people fix your issues if they don't want to

> no one asked for improvement

That's not quite right, SpaceFreak aka Tracer - I've seen various members suggest changes.

so it's definitely not 'no-one' that asks for this

Guus: well users arent admins so :fart:

So if we have consensus how this can be improved, and someone is willing to put effort into it and improve it, why stop him?

I think it's important to listen to everyone - even more so as the people that I've seen ask stuff are members of the XSF, and highly active members at that.

flow - for my part, we don't spend any effort on it. If there's a strong feeling amongst membership that we should, then I'll happily oblige.

~

(sorry, that was me trying to get ssh to disconnect because wifi outage)

Guus, I probably didn't express myself very well, I am sorry for that. My point was mostly that people don't have to oblige to anything, or spend time doing someting. You do not even have to particpate in the discussion(s). But as soon as we have consensus that e.g., the list if non-votes in the meeting minutes is desirable, and someone is willing to put in some effort/time and make the necessary adjustments, then there is no reason to not do it. Or am I wrong?

flow I was just saying that if it were up to me, we'd not apply many of the changes that I feel are maybe an improvement, but don't really add value. If a good deal of the membership thinks differently, then (board hat on) I'd happily conform to the wishes of the membership.

in other words: I'll happily carry out the wishes of the membership, even if I don't think certain changes are needed.

but as I don't see much added value in some of the things that have been discussed recently, I'll not spend to much time on it, unless instructed to.

(I'm happy and comfortable to recognize that I sometimes disagree with others)

Ok, I wasn't expecting that board members need to state that they will carry out whishes of the membership if they do not see any harm in doing so.

I'm not sure if I understand that last sentence 🙂

If I see _harm_ in doing so, I'll try and stop whatever it is, or step down from board.

Guus, I feel it's normal and nothing that needed to be stated explicitly that you agree to stuff that you do not disagree with

What we're talking about here is not something that I think is harmful - it's rather a poor return on investment.

exactly, so you have no incentive to block it, and if someone else feels like it is helpful and does the work, why stop him

I'm thinking we're basically saying the same thing, but misunderstanding each-others words?

probably

good. Back to work with me then 🙂

I hear that people in the XSF tend to use very complicated English. That's probably why.

What, no tripple negatives? Who are you and what did you do to Kev?

It's a good question.

I have _the best_ questions

(ok, back to work with me)

"cosmetic issues", ralphm, I'd like have this piece of mind and think that's just comestic issues.

Kev: or complicated formulation + deepl.com translate ;-) (no shit)

> good. Back to work with me then 🙂 zurück zur arbeit mit mir? sounds exactly like german right?

Also, "lot of actual work that that volunteer time could actually be put to use for", maybe we could make it so that "The Secretary" is a team instead. (as in bring in more people, or people with more time, or actually pay people.)

pep., flow: you can(should) take part but not like : "use my code now"

I guess the takeway is that it does not matter (as board member) if you think something is not worth the effort, but not really harmful either, if it is someone else who is volunteering to do the work. And I guess board shouldn't try to manage the volunteer resources, because in volunteer organizations you can't instruct people how to spend their time, they will spend their time as they wish anyways (which usually yields the best results)

that is a good summary

There is still a foundation to run though :/

flow, I agree with you for the most part, minus ^

pep., to be frank, I have to idea how much time and effort goes into running the foundation. could be a bank account and a post box somewhere which one person once in a while checks

and, as far as I can tell, and while we had and have some issues, e.g., finding a treasurer, running the foundation seems to work

deepl.com deep translate

enjoy

Funny detail https://gitlab.linphone.org/BC/public/linphone/merge_requests/474/diffs#cabe58cc52506439c27d6eca77272251f3e53ac4_55_59

urn:xmpp:ephemeral:0. Fortunately it's not like this namespace needed to be registered somewhere

relevant: https://xmpp.org/extensions/inbox/ephemeral-messages.html

Ah I remember the discussion around that

https://xmpp.org/extensions/xep-0313.html#filter is anything extending these 3 fields already? "Other fields may be used, but are not defined in this document"

ejabberd has an additional field to search the body text FWIW.

non-standard?

Yeah.

There's no standard field for that purpose.

I didn't know that. I was planning to write a XEP for search

search for "This message is OMEMO encrypted"?

pep., yes its standard

there is no need to register fields

The problem is that plain text search is boring, and advanced search varies by implementation

https://xmpp.org/extensions/xep-0313.html#query-form

jonas': Yup.

MattJ: Yup.

ejabberd just has boring search.

Good to know

Holger, your client is incorrectly completing my nickname (assuming that you used features of your client to generate that `jonas'`)

I think registering something standard for boring search would be a good start

"how to buy a tunnel boring machine"

jonas': You told me so in the past, and we still haven't switched to UTF-8.

All I can do is try my best not to talk to you in the meantime :-)

lovetox, I see. That disrupts my plans a bit..

pep., what plans?

What what

One struct to rule them all

Holger, ah, I knew I told someone, but I didn’t know whom :)

If I can't statically know in advance

You can if the additional fields have disco features too

MattJ, you tell my compiler to do the disco to run against your code? :P

So it generates a struct that matches and then every client use it

MattJ, for what if i can request them via IQ?

I'll have to do that differently

pep., you can't implement what you don't understand in that kind of system anyway, so why bother?

these are custom searches, you are not going to request mam messages automatically on connect

Just implement the standard ones in your struct

MattJ, but I don't want to prevent people from querying more

Well you do

So I'll need to allow for optional fields

or you wouldn't be trying to define such things at compile time :)

it's a matter of adding another attribute `moar_fields: Vec<Field>`, but that's a bit ugly

pep., in aioxmpp, there are two layers: you can either access the raw fields (Vec<Field>) with helper methods, or you can use a declarative form wrapper around the original data to access it more sanely

(including stuff like validation)

hmm. I could do that I guess

this type of two-layer approach also helps with applications which need to operate on things more generically (since it provides an individual uniform interface on both layers)

and if you make the declarative layer easy enough, it’s also extensible for proprietary (or simply new) extensions

https://dpaste.de/Zyeq that's what I have in mind. Or a mix of both or..

The current design is meh because most used options aren't validated

In the end I think I'll have almost the same design as the original, with `form: Option<Into<DataForm>>`, providing a helper struct with common options.

it's crazy the amount of <presences> messages that a client is receiving overall

compared to <iq> and <message>

It would be nice to do some analysis some time and figure out what the stanzas are, at a high level

e.g. what percentage of them are actual user-initiated presence changes (my guess is a very small fraction)

and of the rest, figure out if they can be reduced

What do you expect them to be?

Stupid noise, disconnects/reconnects and stuff

CSI makes it less of a problem, but fixing issues at the source would be better

Maybe there isn't a problem. But I bet there is :)

There's rarely a time I look at a real-life XMPP stream and don't find something weird happening

That's the reality of such a diverse network, but it would be good to fix any obvious issues

I suspect in practice the fix would be servers selectively dropping/merging stanzas

And the tradeoff would be more state for the server, and slightly more expensive stanza processing, leading to less bandwidth/battery usage for clients.