GuusNyco and Martin apologized, MattJ probably responds after this ping.
jonaswas it has been foretold.
ralphmAny new things not in Trello?
Ge0rGThe Pidgin vote.
GuusIs that a board issue?
ralphmI don't know what that means. Ge0rG is this a serious topic?
MattJI think Board are being asked to resolve a difference of opinion, in summary
Ge0rGralphm: semi-serious, it's about https://github.com/xsf/xmpp.org/pull/425 and whether we want Pidgin on the list of XSF-approved XMPP clients
ralphmI'll add it to the agenda
ralphm1. Minute taker
Guus(not me, this time)
Guus(also. did I forget to do it last time?)
jonasw(can’t promise anything (like, not leaving in the middle of the meeting for an hour or two), so won’t volunteer)
ralphmWe're done at 14:00 UTC
jonasw(I’m aware. that doesn’t change it unfortunately :()
ralphmI'm going ahead hoping somebody does this, even retroactively
MattJI'll do it
ralphm2. Topics for decisions
ralphmWell, I guess we have the PidGin item
ralphmCan somebody give a summary?
jonaswralphm, somebody tried to renew the listing for pidgin on the client list, and some people raised voice against it being listed there.
jonaswfor compatibility reasons
ralphmI don't think this list has ever been a Board topic before
Ge0rGthe intention of the new software listing rules was to rule out unmaintained software and software where the developers don't care about the listing. There is a very implicit requirement of project members submitting the item.
jonaswI’m pretty sure that it was discussed by board when the renewal-policy was introduced.
Ge0rGIt was indeed. Roughly a year ago.
ralphmI mean we didn't make decisions on the content of the list
MattJIt was a definite shift in the purpose of the list though
Ge0rGI don't know if #425 was created by a Pidgin project member, and technically there _was_ a new Pidgin release, so it's not unmaintained. But everybody agrees that it's a horrible XMPP client and maybe even that it's damaging XMPP's reputation
MattJWhat we had before was an extremely long directory of every XMPP (and Jabber) software ever written
MattJand we agreed to introduce changes to ensure the list is more current, by requiring projects to re-list periodically
Dave Cridlandhas left
GuusWithout enforcing a ruling, perhaps board can offer an opinion?
Guuswould that suffice?
ralphmWho maintains the list?
KevFrom the peanut gallery, I think if this is a Pidgin person asking for it to be listed, it should be listed, otherwise not.
jonaswwhoever has power over the merge button, taht’s at least guus and me.
Guuswhoever has commit rights.
GuusI'm not sure if we have a defined WT for website maintenance.
Ge0rGKev: formally, you are right. But IMVHO this is also a subjective issue of whether we want to serve our community well.
KevI agree, but I think we either have to curate the list, or not curate the list, not having uncurated except for one excluded project.
GuusAnswering the peanut gallery: I'd not be opposed listing software even if it was asking to be listed by end-users, instead of developers.
GuusI would, however, not oppose a semi-objective "compatibility" rating for each of our listings - if it's not to detailed.
Ge0rGKev: as it is right now, this list looks like the officially endorsed clients™, and I'm not sure we really want to endorse every client that applies for the list.
MattJGe0rG, I share your opinion that Pidgin's current situation is not helping us, but I don't think we've actually made that decision to make the lists "only software recommended by the XSF"
Ge0rGOn the other hand we don't have a proper way to objectively describe client quality
MattJand that's a difficult subject that has never been solved in the years we've been discussing it
Ge0rGMattJ: I'm talking about the impression to new users, not about our internal bureaucracy.
Ge0rGI'm well aware that my counter-point of the PR (probably) not originating from a Pidgin developer is just a fig-leaf excuse to not have it listed.
GuusI think it is useful for people to know that Pidgin can do XMPP (even if its implementation is crappy, at best).
KevI think the best objective measure we have at the moment is "Has the project itself asked to be listed".
Ge0rGGuus: people who already use Pidgin are probably aware of that. Do you want people who are learning about XMPP to end up with Pidgin, though?
KevIf the project itself doesn't care to list itself as an XMPP client, that suggests to me that it's better off not listed.
Ge0rGKev: I think (hope) this is uncontroversial.
Ge0rGOTOH, Guus disagreed earlier today.
KevGe0rG: Guus was disagreeing :)
ralphmI have to agree that what Kev said is the only objective thing we have
Ge0rGshort of verifying the Compliance Suite 2018 compatibility.
Ge0rGBut if we enforce that, we will end up with a _very_ _short_ list.
ralphmAnd I might not like Pidgin, but that's subjective. If you want objective, you need to say: all listings have to comply with something, like the Compliance Suite. I don't think we did that before.
MattJOk, so I think we need to make a decision on "project members only" or "anyone"
KevWe did, FWIW.
MattJKev, in the past you mean?
KevAt the Summit where this policy was created.
KevAnd it was Project Members Only.
ralphmIs darkpsy3934 a project member?
Ge0rGin that case we should make it more explicit in the README.
GuusI don't recall (not saying it's not true), but I certainly do not enforce that.
MattJKev, defining project members is tricky for FOSS
Guus(as I don't know how to enforce that)
MattJcommit access? maintains the documentation? Non-coding community manager?
Ge0rGMattJ: it's tricky, but something like "does regular contributions and can influence (the other) developers" would be a good start.
Ge0rGMattJ: once we get a hold on somebody who cares and can do that, we can shame them into implementing the most basic interop things. Like the 8-years-pending Carbons support.
MattJI think we need to separate the Pidgin situation from this :)
MattJIf we're not setting a baseline technical requirement, Pidgin qualifies
Ge0rGMattJ: that was just a figurative example.
MattJand I assume they have at least 1 active team member, who will ultimately ask us to list the project
GuusI think we'd best not add any complexity to that adding-things-to-the-list thing.
ralphmMattJ: I agree
MattJSo the question is simply what our requirements are in general
ralphmI understand Ge0rG's concern, and probably agree that I'd like Pidgin to do better, but I don't see enough reason to reject this request.
Dave CridlandWell. 1) Are there any requirements on the software listed. 2) Are there any requirements on the person listing.
Ge0rGralphm: Pidgin has failed to do better for a very long time now.
ralphmI'd prefer having a list of clients that at least one person cares about, over an overengineered process.
Guusralphm, that's the gist of what I'm thinking too.
ralphmAFAIK the only requirement is 'somebody asks for inclusion at least once a year'
Ge0rGralphm: having a software listed on that page is (to an outsider) equivalent to us, the XMPP organization, endorsing its usage.
Dave Cridlandralphm, Could I submit bash?
Ge0rGDave Cridland: ITYM openssl s_client
Dave Cridlandralphm, Could Donald Trump submit the White House Website?
GuusDave, you could submit it, but I (as someone who has the ability to merge the request) would reject it
Dave CridlandGuus, On what grounds?
Ge0rGGuus: on what grounds?
Guuson my semi-objective opinion that it's not an XMPP client or server.
Dave CridlandGuus, Because you're telling me now there's a line. I'd like to know what that line is.
Ge0rGGuus: it fulfills the technical requirements.
ralphmDave Cridland: please suggest an alternative
GuusDave: I've previously not accepted PRs for projects that were silos.
Guus(xmpp based silos, but silos)
Ge0rGralphm: "a project member submitting the project to indicate that they care about XMPP"
Guusthere's a degree of subjectivity in there - and I'm fine with that.
Dave Cridlandralphm, I'm trying to find what the current policy is, before suggesting a new policy that differs.
ralphmTBH, an XMPP client is something that implements XMPP IM
Guusas a point of order: I can't overrun this meeting. We should conclude this, or resume next week.
ralphmWe have no objective requirements on UI
Ge0rGralphm: so a text window where you enter XML qualifies?
ralphmDave Cridland: I think the current policy is: somebody can submit an XMPP Client (whatever that means) once a year, and it would be included.
MattJI think this discussion isn't very useful right now
MattJPidgin is no doubt an XMPP client
KevIf the criterion is "Person with website commit access gets to choose whether it's listed or not", then we should say that. I don't think it's a good policy, but at least we'd be stating it, and it's different from what we've stated before.
ralphmGe0rG: I want to note that compliance suites also have no such requirements
Dave CridlandKev, +1
Ge0rG> To achieve this, the XSF Board has decided that all implementations have to reapply once per year, to ensure that they are still actively maintained and that the listed info is accurate.
Ge0rGThis is from my mail to jdev@, Thu, 23 Mar 2017
ralphmI think all of this work is best effort and there is no completely definitive answer. Some person is going to accept or reject and then maybe somebody else has opinions later
Kevralphm: Then just go with my suggestion above.
MattJI propose that we currently vote on whether to accept this PR. If someone objects, state why so we can resolve it for next time
KevIt is clear. Not good, I think, but clear.
GuusKev, where 'website' is our website, not the project applying, you mean?
ralphmMattJ: but I don't want to have to vote on this every time.
KevIf we're being arbitrary about it, it is best to be explicit that we're arbitrary about it.
MattJAgreed, neither do I - but what we decide ultimately sets a precedent and we can document it
KevRather than pretending we have one rule, and acting on another.
GuusKev: I don't agree that it's needed to be explicit about that (don't mind to much either)
KevI'm vanishing now anyway.
ralphmIn that case, I move we accept this request to add Pidgin on the grounds that it is an implementation and somebody wants it added for another year
GuusI think we're somewhat overcomplicating a proces that has worked pretty well so far
Guusit's jsut this Pidgin thing that now acts up, which is understandable.
Guusalso, I need to be going. Can stick aournd for a couple more minutes at best.
MattJI'm -1, because I think we should limit submissions to people affiliated with the project to ensure accuracy of the submitted data
MattJand it's not clear that this person is affiliated in any way, other than as a user
Guusmattj, the person merging assures accuracy.
Guus(at least, I check if the name / website exists, and that's pretty much it)
MattJIf all the data is trivially verifiable, then I'd be fine with that
Guus"all the data" is just the name and link to the project site
Ge0rGI still think that this is a huge disservice to our community.
MattJOk, then I'm +1
GuusGe0rG, I hear you, but I disagree.
HolgerFWIW, I would think Compliance Suite compatibility would be a good criterion. The resulting list will be short because there isn't many good clients, but I don't see how it helps the end user to make it longer by filling it up with not so good clients.
Ge0rGHolger: it could end up with Conversations as the only client.
GuusRalphm, can we conclude the meeting please? 🙂
MattJI think as a separate task, we should add a field for latest supported complaince suite
MattJBut that's for another day
HolgerGe0rG: I'm not sure that's true. If it is, so be it.
GuusMattJ: some form of conformance should be added, yes. Not sure if it needs to be compliance suite or not.
Ge0rGGuus: it's the most logical one.
ralphm4. Date of Next
Guus(no aob for me)
Guusthank you, and goodbye
HolgerMaybe the Compliance Suite or the referenced XEPs need fixing if nobody is able to implement it.
HolgerGe0rG: But doesn't Gajim also meet it? And maybe even ChatSecure these days?
HolgerMaybe also JSXC and/or Movim ...
moparisthebestI would also like to see License listed there