XSF Discussion - 2022-08-11

We just realized that at least one member was not on the XSF members list. If you are member and haven't yesterday received an email via that maillist you should ask iTeam possibly Alex: fyi ✏

emus, can you send me more details? Will fix then

wurstsalat: ^

hmm I think I am not on the members list

at least I did not receive an email

related thread: https://mail.jabber.org/pipermail/members/2022-August/009429.html

https://mail.jabber.org/pipermail/members/2022-August/subject.html#start

general threads

flow: fixed your address

Alex, thanks :)

Cleanup in the morning 🥰🧹

Sam, re: https://github.com/xsf/xmpp.org/pull/1161 I am very much opposed to adding new fields to {clients,servers,libraries}.json I remember we discussed this here some time ago, and it was the sentiment that we should rather have less keys in these json files than more. As you are aware, DOAP files do offer a logo section, so this would be another duplicate ("os" being the other duplicate). I offer my help for anyone struggling to create a DOAP file for their project

I cannot create a DOAP file with my static site generator and it's not documented anywhere so I don't want to maintain one manually.

I don't need help, I just don't want to be a second class citizen on the site because we insist on overcomplicating everything.

If you're volunteering to maintain a doap file for my project for all time I suppose I really appreciate that, but it seems unsustainable since you'll probably get burned out at some point.

Sam, the idea is to maintain your doap file manually (which is machine-readable), and render it on your (static) website, like here for exaple: https://gajim.org/support/extensions/

As I said, it's not documented so I don't really want to do that.

Sam: in what way is it not documented? Does the spec not count as documentation?

What spec? I looked everywhere and no one could link me to one

I just got "read the code" a lot.

https://xmpp.org/extensions/xep-0453.html

oh, fair enough, that problem was solved at least, my bad

This must have happened after the last time I complained that "read the code" isn't acceptable, I really appreciate that

Still, this format is garbage and I don't want it on my site. I previously had my thing listed by something on the XSF site and I'd like to keep doing that.

Sam: at some point you will have to admit that you simply do not want to write a simple XML file because you have an opposition of principle, and that is fine and nobody will force you to do it, but please don't try to limit what people want to do with it just because you do not like it

Yes, I admit that, this is garbage that hurts the ecosystem and community and I am absolutely opposed to it. I'm not just complaining though, I tried to come upw ith a reasonable alternative.

("Garbage" is all very subjective)

Sure, but I've given all the many reasons I think this is a terrible idea that we shouldn't be doing (or at least shouldn't be doing without alternatives, if people want to do doap files for their stuff that's obviously none of my business)

Anyways, I provided a PR so that we can have fewer projects that look ugly and have no icon on the website, I'm not interested in re-litigating why doap is a bad idea, I have obviously lost that fight.

What if the intent is to encourage adoption of doap?

Could be; obviously I'm not going to, maybe everyone else will. In the mean time I'd still like my project to look nice and have the ability to have the nice features like the icon the others have.

Does it stop with a logo though?

I don't know if maintaining an additional format for one project is worth it

We already maintain two formats.

We have the list, yeah, and you're wanting to duplicate everything in DOAP into that

I don't know if it stops with the logo or not, that's the only new feature I can see on the website, so I suppose that's it. Maybe if we add other info from the DOAP later it will also be necessary to add it to the json, depends what it is

As I said, I'm opposed to adding new keys to these json files

You're in fact moving the maintenance burden, since you don't have to maintain a DOAP file, but I have to account for all duplicates there are..

I'm moving it? You just moved the maintenance burden to me, I'm just shifting it slightly back for a single key and like a 2 line patch.

Anyways, doesn't matter, I appreciate you letting me know. I still think if we're going to do this DOAP nonsense at least the basics need to be in both places for projects that don't have it.

> Sam wrote: > I don't know if it stops with the logo or not, that's the only new feature I can see on the website, so I suppose that's it. Maybe if we add other info from the DOAP later it will also be necessary to add it to the json, depends what it is That was the statement and question of the mail (where also the link to doap xep has been placed btw). We want to expand the information for users based on doap.

> Sam wrote: > Anyways, doesn't matter, I appreciate you letting me know. I still think if we're going to do this DOAP nonsense at least the basics need to be in both places for projects that don't have it. We left the json as it is for years if I see correctly. The new rendering features base on the xep standard.

Sam: Why isn't it okay to place a doap with four entries? Name, url, url_logo, os? Likely no need to maintain, right?

emus, give up. Sam hates angle brackets, and we've had this discussion too many times :)

Look, I tried to do this reasonably and just submit a fix. If it's not wanted, fair enough. I obviously can't talk about it reasonably without going on a rant so I'd rather not have this discussion again.

ok

My view of the situation is: we have consistently (for years) struggled to maintain the software listings. Shifting more responsibility to project maintainers is a good thing. We needed a format to describe a project, and rather than invent one we used one that's already been made and deployed. It happened to use XML. That's apparently enough for a small number of people (1?) to object to using it. That's fine, we agreed we're definitely not going to ignore software projects that don't provide the additional metadata. Does that mean we should continue to expand our existing ad-hoc JSON with all the additional stuff? I don't think that's worth the initial or ongoing maintenance effort for one project.

I'm not strictly opposed to adding fallback code for logo, but I really don't think it could stop there if we added XEP support comparisons, etc.

MattJ: +1

my 2 cents: one fallback will never be enough, write a DOAP file or don't have your project listed on xmpp.org, just list it elsewhere ¯\_(ツ)_/¯

I think there's value in being able to list projects that don't (e.g. yet) have DOAP available, in some form

for a limited amount of time imho

I'm pessimistic that we can manage 100% DOAP for all projects that we'd want to list on the site

would it make sense to convert the (minimal) info that is there into a (minimal) DOAP file hosted on xmpp.org, and to either accept PRs from the project (for the minimal data) or to require them to host their own DOAP with more data?

then we don't list them, oh well, there's all sorts of XMPP projects not listed there, always will be

the devil's advocate claims that listing your project on xmpp.org is a privilege, not a right.

It's the "oh well" that I'm uncomfortable with. Regardless of why they don't have DOAP, I think we lose value if we can't list them at all.

it clearly is a privelege as opposed to a right, I'm sure a XMPP project could exist that we would refuse to list :P

Ge0rG, I don't think you're wrong, but from the perspective of "we want xmpp.org to be useful" I think that doesn't help us achieve the goals

and yeah, I think we've discussed hosting DOAPs for projects before

DOAP's don't actually have to come from the project/maintainer right? like if project X was particularly useful and didn't have one, I could host it at mydomain/x.doap ?

Sure...

so what about: a) we host a barely minimal DOAP for projects that somebody volunteers to keep listed (in form of a PR) with minimal QA or b) a project hosts their own DOAP

then why add fallback for non-doap, you aren't actually restricting anything

moparisthebest: that's technically possible but I think that control over the DOAP should be either with the XSF or the project maintainer, not third parties

that also seems fine

No, we never were restricting anything. The problem isn't "where to host the DOAP" but who will create and maintain the DOAP. We have a non-zero number of people who seem reluctant to do either, and I don't think it should be up to the XSF's web team to keep that up to date (which hasn't gone well in the past).

right, so that makes the rule simple, if you want a project listed there, write your own DOAP or find someone to do it for you, or don't have it listed

MattJ: so the two positions are "the XSF web team wants a certain project listed" vs "the XSF web team doesn't have the capacity to maintain a full-fledged DOAP of that project"?

why would anyone maintain a DOAP beside the project maintainer

that sounds insane

lovetox: please don't

lovetox, because the project maintainer refuses to, yet we still want to provide info about this project on xmpp.org

We basically have that fallback for projects with no DOAP already, but it doesn't support logos

and we also want to extend the site to include additional info about projects, so this will only become more painful

so the XSF can host DOAPs for projects people want listed where the project doesn't have one, if no one is willing to create one, then no project listed, easy

this is a slippery slope, isn't it?

less slippery than all the code required to add json fallbacks

Yeah, it might be the best route

Hardball it! Trade: DOAP in exchange for nice listing.

It's not too bad if we just have to host a static file for people who use static site generators that don't support static files

Definitely require DOAP for if/when we show calculated compliance listings based on DOAP XEP info.

MattJ: I think the challenge is in accepting PRs to those static files whenever something dynamic happens, and vetting whether the PR came from the respective project (which we already do (not do) for the JSON anyway) ✏

Zash, sure, that comes automatically from "let's not add more JSON fallbacks"

Where to draw the line tho? name, description, logo?

The question is whether we want to maintain *that* info in DOAPs hosted by us

Ge0rG, PRs to those static files will explicitly *not* come from the respective project

if the project was willing to create a DOAP, they'd do it themselves

moparisthebest: I'm not sure about that.

there will be projects not willing to create, but maybe also not willing/able to host

And what kind of static site generator can't serve a static file?

it's just about project maintainers unreasonably refusing to create a DOAP

it's not a static file generator.

I observe that a bunch of projects just point directly at their version control

I'm referring to > I cannot create a DOAP file with my static site generator and it's not documented anywhere so I don't want to maintain one manually.

imho that's why they should just be excluded, but allowing others to do it for them is a reasonable alternative

it's really interesting to see how much time can be spent collectively, repeatedly, because one person refuses to spend a bit of time.

that's why I originally suggested just not putting them on there :) their choice

Well, it's going to continue draining our collective time unless we decide on a policy for the future

Next step is: we need a Board decision what hoops a project has to jump through to be listed.

Wasn't there a goal to get rid of the annual "renewal" things and replace the decision with something DOAP-based?

I'm leaning towards just hosting basic DOAPs for projects, but none of the advanced stuff (XEP support, etc.) because that's too much of a burden to maintain

MattJ: +1 on that

question: our DOAP changes regulary, i would not like if i have to update it on the xsf site, could i not supply somehow a link to our doap and the website pulls it every week or something?

there is really no point to re-invent the DOAP fields in legacy JSON

lovetox, that's exactly how it's supposed to work

lovetox: that's the default

We're discussing people who refuse to do that

ah cool, then continue :D

lovetox: hosting DOAP on xmpp.org is an _option_ for projects that can't afford hosting an XML file

So I guess it just remains for wurstsalat to reveal whether this is feasible (providing basic in-repo DOAP files for certain projects). I'm assuming it wouldn't be too hard.

right, that seems reasonable, and XSF folks should just click merge, if it's incorrect anyone who cares can fix, and if the project maintainer didn't want incorrect info in there they should host their own

it's just a URL right? presumably script doesn't care where it's hosted

bonus points for relative links?

> providing basic in-repo DOAP files for certain projects should be easy to do but where to start? add all non-outdated non-doap packages? add all which have been updated at some point, discard the rest?

wurstsalat: add mellium because of the logo right now. then maybe later migrate all the JSON data into mini DOAPs and get rid of the JSON code, if possible

It's up to you. We could even just do it for this one project for now (due to the logo request), and decide on the others (port or drop) at a later date

I think the `last_renewed` question is still unsolved with DOAP, right?

Yeah

so the JSON _at least_ has to contain `doap` and `last_renewed`

I think we'll phase out the last_renewed logic eventually

so it doesn't make any sense to _move_ from JSON to DOAP

MattJ: I fought hard to get it in!

I won't oppose to moving it into DOAP though

Yeah, but admit, it was always a proxy for "is this a good modern XMPP project?"

for the minimal doap, i guess you dont need to list xeps, only project information, and thats ver likely to stay correct a very long time

and I think DOAP makes other (better) signals available to deduce that

MattJ: bummer, yeah. So if we get Compliance Suite status, I'm fine with removing `last_renewed`

Exactly

That's actually a great way forward.

alright :)

I just integrated Zash's `compliancer` last week, so compliance data isn't far away

So the change *right now* is minimal: just add support for in-repo DOAP, port Mellium to that, add the logo

I would remove mellium and have whoever actually wants it listed there do it :P

Our goal is having a useful website, not arguing about whose job it is to make it useful :)

This discussion reminds me a lot of how like half the apps in fdroid have no logo listed because the requirements are a bit weird and some projects just don't bother 🤷‍♂️

singpolyma, and the conclusion is that we'll host it for them, all they need to provide is a URL. Is that too much bother?

MattJ: no idea, just surprising to me how little projects care sometimes. I mean, I do get it, some of my "basically just for me" projects don't even have a readme, all depends I guess

I have no stake in this decision since it doesn't affect me on either side, but it's interesting that the issue isn't isolated to any one community or format or publisher ✏