XSF Discussion - 2019-07-25

and... time?

fresh waves? we beat records in temperature in Paris

I'm in a Burger King... :'(

#itsnotjustparis !

same here 🙂

well, I'm not in a Burger King.

Something something makes you wish for nuclear winter.

at least I gotta milkshake

maybe not nuclear winter, but something in between, like planting trees, reduce waste...

ralphm MattJ Seve ?

I'm here :)

I was just thinking on a funny sentence, but nothing came out.

quorum

Here

Sorry I'm late

cool

who leads?

our (burger) king of course!

anyway, I had just one question: should we enlarge the poll on compliance badges to Standards@ instead of restricting it to Members@ ?

I don't mind.

is there a need to gather more feedback?

Let's do this properly.

0. Role call

everyone but Ralph has made a noice

_o/

everyone but Ralph has complained about heat :)

0. Agenda

apart from what's on Trello, and what Nyco just said, anything else?

I'm good

Nothing here

1. Minute Taker

volunteers?

😕

2. Vote on Github contribution

I saw it, but I haven't made my mind yet, sorry.

a lot of stuff is highly obsolete

I'm all for merging, because that's done anyway

a contribution is a contribution

In short: we had someone that renewed many of the projects that are listed on our website. From what I can tell, the renewals itself are semantically correct. There was a debate wether or not we'd require _people involved_ with a project to renew them - or if we'd allow anyone to do it.

we still have no high-level, world-class XMPP app

Are we comfortable voting on this today, or does anyone want more info/time?

From the floor, as the one who brought us into this mess, I'm strongly in favor of requiring somebody involved in the projects to do the renewal.

background info is linked to in the trello issue.

As we don't have any other proxy info on commitment to xmpp from the developers.

maybe that rule was not our best move...

I see the intention though

I disagree - the list is on our website to facilitate finding useful things, not to pull in XMPP developers from the listed projects.

(I'm just reviewing)

the same goes for Vysper, btw just revived... or not

nyco I'm aware that there's a lot of gray area here.

Guus: yes, and things are only useful if they are still maintained.

Ge0rG - or heavily used.

Compliance Suite would be another proxy, but then most are out.

that's the art of decision making: lacking clear black and white frontiers

Guus, it would probably be smarter not to encourage using unmaintained software, hence having developers chip in

Guus: unmaintained clients that are heavily used are a major burden for our ecosystem.

Also - there's no practical way for the website editors to verify that people providing a PR are sufficiently associated with the project that they're renewing

pep. I agree with that, well I agreed with that originally

Guus: I'm not speaking about 100% enforcement, but about clearly communicating.

we're still neutral, or more precisely wanna be

Simply asking in the PR whether the author is involved would be fine by me

I think that with what we've done with the renewal, the quality of the list has dramatically improved. I'm not sure if putting in more enforcement effort would be worth it.

Also, I think that the PR that's outstanding now, would benefit the website.

I'd hate to reject that PR, simply because its author is not associated with most of the projects there were renewed.

I think I'm in favour of accepting it

we still need better to qualify the quality, maintenance and modernity of a piece of software

Guus: can you verify that all updated projects are actually still maintained? Including their xmpp parts?

Ge0rG, I peeked at a few random samples, and it seemed so

just some websites are still up, dunno why

Ge0rG I've run through the list, and verified that most of the renewed projects indeed had activitiy

how can we truly check?

ask for declarative info from the owners?

nyco we can't without spending much more effort than I think is wise to spend on such a list.

Pidgin also had activity. Nevertheless it's stuck in 2005, xmpp-wise.

agree, exactly what I wanted to point at

Psi(+) is the same

maybe not Gajim

anyway

chair? we take a decision today?

So, we now have a list of which 20% of the items on it are debatable, against more than half, before we had this procedure. That's good enough for me, to be honest.

I suppose you can just have a Board vote on this specific PR, for an exception to the maintainer rule.

or we revoke the maintener revival rule ;-)

I'd prefer to make this a vote on the rule, not on a specific PR

to prevent this from coming back again.

I'm not in a position to prevent that, so do go on.

if we cannot have that vote today, then I'd like to vote on just the PR today - to ensure that the author gets feedback.

So what would it be? We remove the once per year check? Or just the acceptance of the change only if it comes from a person related to the specific project?

we keep the rule, make an exception today, reconsider the rule later?

I propose that we vote to allow a renewal/listing of a software project from anyone - not just a project associate.

*Is* there a "maintainer rule"?

yep

https://xmpp.org/2017/03/new-xmpp-software-listing-rules/

hey guys

flow: it's noted in a blog item, which I suspect is taken verbatim from the then-board descision.

I thought these rules were precisely to prevent random users from asking to revew Pidgin?

oh

Zash: no, they weren't

they were there to be able to remove unused listings.

Board, are you comfortable voting today? If not, I'm punting this to next week.

what do we vote?

Hmm it is not really explicitly spelled out in https://xmpp.org/2017/03/new-xmpp-software-listing-rules/ AFAIKT

I propose that we vote to allow a renewal/listing of a software project from anyone - not just a project associate.

right flow

is there a place where i can make a thread about xmpp??

Guus +1

i havent been able to find a fourms

MattJ what do you mean?

Matt is a different person than MattJ.

yeah

Matt, can you wait a bit please, this chan is currently used for a board meeting

yep, just saw this

uh oh

im sorry

Matt - we're in the middle of a di...what pep said. 🙂

no worries.

Seve, MattJ?

I'm ok voting now

Seve?

But the vote is simply allow/disallow, right?

I have to say I prefer the middle-ground: allow by maintainer by default, allow exceptions if necessary

This PR is exceptional because clearly some work was put into it

MattJ: requesting renewal doesn't automatically mean acceptance.

Ok

I would favor allowing everyone until there is a mechahism in place which only allows updates by registered (mail|xmpp) addresses FWIW

so this is about who may open a PR on the website?

I'd prefer to vote on allow/disallow - to not have this keep coming back, which I think is wasteful of our time. If you disagree, feel free to correct me.

let's not make it too strict and too complex and too formal and too restrictive

flow, maybe once DOAP is democratized we could use the author list there :)

"Should non-maintainers be allowed to renew a project listing?" is the vote then, right?

once DOAP is deployed, we don't need to maintain a list. It would be auto-generated from the DOAP records.

MattJ: yes.

true

Guus, sorry, I'm just having difficulties on what to do. I would like to have a thought or two about what do we expect from the list, but anyway this will change on every board.

but I'd first like to heaer from Seve ✏

Ge0rG, which might not be better tbh

s/heaer/read/

Seve, if we postpone the vote until next week, does that help you?

We don't have control over who commits on each client

But we could very well list them if they support X or Y. For future discussions I guess.

Guus, I'm on the side of having better quality over than quantity, but I think that's not possible right now as nyco said. I will be+1 on the vote, then.

honestly, doing a release is a very long checklist if authors delegate that to other people, that's cool

Ok, so, you're OK to vote, I gather from that. 🙂

For the record: I motion that the XSF should allow non-maintainers to renew a project listing on our website.

I presume that my disagreement and its motivation has been logged.

Ge0rG if only we had a minute taker...

or: it'll be as logged as the outcome of this vote.

technically, logged, yes

http://logs.xmpp.org/xsf/

nyco, seve, mattj, can I have a vote for the chat log please?

+1

-1

Guus you vote as well :)

I'm +1

Oh wait, we agreed it still needs review/approval, right?

I read that as "editors will approve renewals from non-maintainers"

> For the record: I motion that the XSF should allow non-maintainers to renew a project listing on our website.

"to renew" or "to request renewal"?

> 15:10:19 Guus> MattJ: requesting renewal doesn't automatically mean acceptance.

If this is the case, I don't really know what this vote is for, since we'd be reviewing individual requests anyway

Mattj, the vote is for a PR not to be automatically rejected, if the PR author is not a project member.

But no confirmation from a project member would be required, right?

right.

I don't want PRs automatically rejected, which way should I vote? :)

required for what? What will editors do with such PRs?

Ok, let push this to next week.

Ok :)

will they be brought up to Board?

We can discuss this out of the context of this meeting

or will editors just decide, somehow?

(I need to go soon)

it's 16:15 past

do we put an end to this meeting?

I motion that we, as a one time exception, accept https://github.com/xsf/xmpp.org/pull/588

nyco, noted.

wait, let me rephrase that

I motion that, independent of the outcome of the pending discussion, now choose to accept https://github.com/xsf/xmpp.org/pull/588

ok

+1 to accepting PR #588

gotta go...

+1

+1

tx nyco

+1

thx all

Ok, that's a full house, motion carries.

3. AOB?

(none for me)

None here

+1

Wow, nice ralphm

Also hi

oh hey

hi ralph

4. Date of next

+1w

+1

Yay

5. End

thx all

Thanks guus

bye

Btw, ChatSecure and Empathy from that PR don't look very maintained. The last actual code change to Empathy was in Sep 2017.

Ge0rG, Don't say that *now*.

Ge0rG, empathy is very much not maintained from what I understand.

dwd: I'm not on Board, so it wasn't my duty to review that PR in time for the vote.

which is just an excuse for me not having uncollapsed all the diff chunks

https://github.com/GNOME/empathy

7 days seems recent

ralphm: The last *actual code change*

Collabora at least hasn't worked for ages on it. And independant devs are not pushing anything anymore. Also there's now a "new" xmpp backend for telepathy, telepathy-nonsense (empathy uses gabble)

pep., Yeah, Empathy's backend was wjjjt's, I think, and he's not worked on it in a decade or so.

Last commit with actual release code changes was in Aug 17, 2017 (not including translation fixes)

(maybe this is just another way to confirm that project maintainers should be involved in the renewal 🤷)

I wonder if much of the discussion that we're having here is caused by a difference of perspective. In my perspective, this list is "good enough" if it doesn't list a significant amount of old/crappy projects - like it did before we had the renewal process. I feel that others try to hold that list to a higher standard.

Although I'd love the list to be "better", I fear that the effort involved would skyrocket - which in my opinion isn't worth it.

That's why I'm OK to settle for what I think is "good enough" (which generally is what we have now)

Guus: I know that some people in the XSF are very focused on keeping the XSF neutral, and listing some implementations while deliberately delisting others is only one small step away from violating neutrality.

Which is why the periodic renewal by projects was introduced in the first place, because it is clearly not a violation of neutrality.

or rather, it provides an objective way to treat all projects, while significantly improving the SNR of the list.

so nobody can cry foul.

SNR?

if the current Board is okay with having editors or the Board decide on non-maintainer PRs based on subjective criteria, so be it.

Guus: signal to noise ratio

https://mail.kde.org/pipermail/kopete-devel/ also looks more dead than alive.

Ge0rG: we could still accept _all_ PRs, without applying any criteria other than very basic ones (eg: is the listed website reachable).

That's not ideal, but would still be an improvement over what we had before the renewal policy (as old/crappy listings will eventually go away, unless renewed)

or at least, I'd be willing to go with that, until we find that those are being structurally renewed, too.

Guus: this allows gaming of the list by project affectionados.

I'm still using my favorite jabber client from 2002, it needs to be on that list!

Not more than what we had before the renewal process.

Guus: I think we agree that before, the situation was just bad.

hey no offense to anyones emotions but why is this chat public?

how do you guys combat people like coming in and start spamming

matt: that's a very minor problem, and typically solved manually by the room admins

Hey Matt, unsure what you mean? We certainly didn't want to come across as rude.

no im not upset

or are you not specifically meaning _this_ argument? 🙂

ah ok 🙂

well, what Ge0rG said. There are moderators here, that can remove people from the room.

pretty cool to see the dev work on a project though

Guus: also please let me remind you of https://github.com/xsf/xmpp.org/pull/425

I still like the original process we agreed, FWIW (someone on the team renews it, it goes on, else not). It was simple (although obviously people can lie about affiliations) and consistent.

matt, Not even the dev work, this is all a meta-level up from there.

huge fan of xmpp been using it for a year now

i hope you guys can come down to nyc some time

matt, Cool. What are you using it for, and what clients/servers/etc?

I think the developers of ChatSecure are located in NYC

oh really?

Also yeah, it'd be lovely to get the US Summits going again somehow.

would totally love a meet up

US summit would be nice to have again!

i mostly use xmpp for IMs and file transfers

Kev: +1

im pretty vanilla

but i wanna implement a new system

matt, Personal use with friends, that kind of thing?

yeah

I'm off to do more work again. Thanks for the insights, Ge0rG (others). Still not seeing it your way though 🙂

matt, Cool - that's probably our biggest use-case, but still most people use Signal/Whatsapp/Facebook Messenger/etc, so it's nice to see.

Guus: whatever makes your Board work.

me and my friends love it

mathieui, So by "a new system", you want to write a new client, or something else?

Guus: but don't mind me complaining in the next pidgin renewal PR

Ooops.

it brings back that old 90s AIM feel that we grew up with

matt, So by "a new system", you want to write a new client, or something else?

I wanna add DND stats to the Vcards

Ge0rG I would send out rescuers if you'd fail to complain on that.

i want to add Real life experience to xmpp

like life RPG but with instant messaging

matt, Ah, you'd probably want to add extension stuff like that to PEP, I'd think.

matt, That's the mechanism that, for example, location, mood, etc all work through.

hm pep

is that a module?

It's a specification

matt, Serverside, it can be. But it's usually built in as standard on any server you're likely to use.

why cant i just edit the Vcard module

We talk about standards here, not code.

matt, Well, if you did that, then no other client would be able to use what you wrote without special support.

ah

matt, Whereas if you use PEP, you don't have to edit any server code at all, and any client can just add the support for the DND/RPG/etc data you add.

Matt, in this room you'll find mostly people that discuss about the protocol, and not so much individual implementations. The goal is to have a general consensus, so that we can build interoperable implementations of clients/servers ✏

very cool

matt, So you'd just edit your client's code to add the new PEP node and its data. Which is less work for you, plus it gives you things like push updates etc, which vCard won't do.

ok so how do i do that with form data

matt, What client are you using?

gajim

From a protocol perspective, you could use any of the features that dwd mentioned as an example. This is the documentation for sharing 'location' through that mechanism, for example: https://xmpp.org/extensions/xep-0080.html

and using ejabberd

(hoping that my random pick of examples was appropriate 😛 )

matt, Gajim, you'll find, already uses PEP for location, mood, user tune, and probably some other things I've forgotten. Dig around in the code and you'll soon find it all.

you guys are awesome

thanks

We're here all week. Try the veal.

come down to nyc

and do a talk at barns and noble or something

you guys would be treated like rockstars here

They use XMPP?

We used to have a pretty strong presence west of the Atlantic, but things have shifted more to Europe in the last few years, sadly.

Guus, Well, it's great for *us*...

badum tsss

I'm happy with a EU-presence, but I wouldn't mind having a US one too. 🙂

A lot of people use MQTT for production stuff

like ecommerce

updating qty

matt, For sure, but MQTT isn't any relation of XMPP.

isnt there a module for xmpp

matt, For ejabberd, yes. As far as I know it's completely unstandardized though.

ah ok

Not that far from saying "We use TCP for stuff"

whats the best way to input xml data?

through a console like the one on gajim or pidgin

Unsure what you mean? You'd rarely want regular end-users to input raw XML data.

If you want to play around with sending raw XMPP, then those consoles are probably a good choice though.

the reason why i ask is cause at some point i want to people to fill out a quiz and it will send it their xmpp accounts

matt: i *think* you should take a look at adhoc commands maybe

ok

Dataforms, perhaps?

matt, XEP-0050.

!xep50

Or this one? https://xmpp.org/extensions/xep-0336.html#usecases

ok i will read this one

dont get how you want to use adhoc commands as quiz to random users

what you should do is just attach a dataform with the quiz to a message

then you go around and beg clients to implement support

Gajim has a plugin that shows a button on messages that have a dataform

so you can press the button the form opens you fill out the data, and press send

actually i think this is underused, a lot of nice things you can do with that

but i guess this is because dataform ui is not easy to implement and most client specially mobile dont have support

Yeah, you need to write a widget toolkit wrapper. Not a pleasant job.

So, buttons?

https://xmpp.org/extensions/inbox/buttons.html with what changes?

Zash, with data forms instead? ✏

You don't really get dataforms that simple

pep.: Like https://cerdale.zash.se/upload/HNcubzSy4lwQv7zP/xform-buttons.md ?

or `<button><{form}x/></>` ?

Zash, looks good to me?

For the security considerations, I guess it's up to the client to be careful to their UI ✏

Maybe we'd need a FORM_TYPE value as well? :/

pep.: https://xmpp.org/extensions/xep-0045.html#voiceapprove

I mean your spec, maybe it could use a FORM_TYPE

There's no specification. This is already a thing.

xform-buttons.md is meant as an informational thing that says "hey you can do this already"

Hm

Maybe you could have a form that consists only of a `title`?

use that as button label

Something to put in a form field indicating "use this input to trigger form submit, instead of adding an extra Submit button"?

`<button>` ?

i like it

Full circle?

`<field><button type="submit" /></field>`

<button> as ui hint, type=submit as behaviour hint

Tho for the use case of just having a few auto replies, xforms is massively overkill

with full xforms though, i can see how i can replicate everything from stuff like slack command bots, that aren't just buttons