XSF Discussion - 2022-11-04

I think it should happen. as always I am happy to support organisation

vanitasvitae: hi. re: XEP-0396 (JET-OMEMO), how would you send the transport secret with TWOMEMO (which has not KeyTransportElements)? Would not a simple XML element with TK + IV suffice as we can use SCE with TWOMEMO? I've made the implementation with OLDMEMO, but I would like to handle TWOMEMO too.

and on an other topic, is there any progress regarding editor troubles? If we end-up without editor in January, we'll have a serious problem. It seems that the board has some money to hire somebody to make the requested improvments, can't we do that?

Who to hire, and what should they do?

MattJ, emus and others worked on making a list of actionable and roughly scored issues in xsf/xeps

ideally, we'd hire someone from the community who already has an idea what they're doing

I was about to say, I don't think what we have is enough to hand over to someone outside the community who is unfamiliar with the process

(or we could, but it would waste a lot of time and resources)

yes, certainly.

they'd first have to read through '1

on the other hand, a fresh mind would maybe clean up a lot of things :)

https://github.com/xsf/xeps/issues is a laundry list of random stuff, where to start?

1223--1227 are the important ones

we could label those with a high-priority label

I'll create an "Editor Tooling" label or something

ack

Okay: https://github.com/xsf/xeps/issues?q=is%3Aissue+is%3Aopen+label%3A%22Editor+Tooling%22

jonas’: I hesitated to explicitly ping you in those tickets to get additional details on what should be implemented, but you helpfully linked to the editor process document.

yeah, there was a round-trip via the board ML which I can read as board<>council liaison

Ge0rG, it is indeed (and already labelled as such)

nevermind ✏

looks like my websocket lagged

maybe board can review what I was writing to them and tell whats feasible

Can we hire jonas’? 🤯

Daniel, I don't want to go through the troubles of that, being employed elsewhere already. ✏

jonas’, the troubles of actually doing the work or the trouble of setting up the system to get paid?

the latter certainly

I'm not sure about the former

If we can make an ordered and refined backlog (for anyone who doesn’t hate such terms), I can *try* to do something.

Kev, https://github.com/xsf/xeps/issues?q=is%3Aissue+is%3Aopen+label%3A%22Editor+Tooling%22

that's the relevant backlog

I could put an ordering on that, it is already partially refined, I guess it could use more of that

Ok. Let’s see if I have any energy on my two hour train trip coming up. Long week.

FWIW I'm currently working on CI plumbing. What's currently missing are some of the tools to run in it, such as linting and sanity checks, mail notifications, etc.

Does that mean you have a grasp on what should be happening?

I don't know if anyone else is doing anything else, though thilo.molitor has expressed an interest

Basically, if there’s something I can do within my 2H window, given train wifi, I can try to do it.

I'm just trying to focus on one small thing at a time, so generally the answer is "no"

I started on what I'm doing because if we have the tools to do what we need, we need to be able to run them somewhere

so I'm working on that foundation first

Do we already have tooling that knows about committed changes, for example? Which XEPs have been changed, anything like that?

No, but that could definitely be extracted from what I'm currently doing

So if anyone works on a tool that needs that info, just define an input format for that and I can generate it

I’m thinking a script that gets run on container startup, diffs XEPs compared to a cache of previous run, sees which have changed version and triggers “I need a mail” from that.

MattJ, seen tools/md-diff.sh ? :)

Consider the diff generation part of what I'm already working on, but nothing more than that

Zash, not in working memory

Ok. I think I’d probably better not try and do anything right now, it sounds like I’m going to just duplicate effort.

goffi: I haven't yet found the time to take a look at JET+TWOMEMO, but using SCE sounds reasonable

vanitasvitae: alright, I may use my own element for now, and I'll update once the XEP is updated.

Since you have a working implementation, you might be in a better position than me in terms of collecting real world experience :D

So feel free to experiment with your own element and then (if I don't come around to it earlier) ping me, so we can copy your element into the XEP :P

OK thanks.

Kev, that's why I'm trying to be explicit about what I'm *not* working on (and one reason I haven't previously announced that I'm working on anything). I'd rather not have the burden of editor tooling fall solely onto me, just because I made a start...

You're the editor now, dog.

🤦

AFAICS, if we want to automate attic generation reliably, we're going to want to enforce squashing PRs.

Unless we're going to be happy (which I think is reasonable, but maybe others don't) with a script the Editor can run when they're ready to trigger publication of new XEPs that would populate the attic, add git tags etc., and then push the result.

Kev, I wish for git tags on revision blocks, and those can be detected/auto-generated in diffs / by comparing xeplist.xml on different revisions ✏

so all we need to enforce that there are no changes to a file in a PR after the commit which adds a revision block

So the logic you want is a script that will: foreach xep in *.xml: extract ver if not check attic for ver: git tag copy to attic commit attic push to attic and xeps.git ?

Not that I seem to have enough bandwidth to checkout xeps.git to do anything with it at the moment, annoyingly.

you don'- need to if not check attic for ver, you'd diff the old and new master

I was hoping to make something easy by making it stateless outside of the repos (i.e. doesn't need to know about git diffs).

It gets tricky. Git itself doesn't even have the concept of a "PR". Determining if "no changes to a file in a PR are made after the commit which adds a revision block" is not super trivial (but I don't think it's impossible)

I don't think I'll have the inclination to fiddle with git like that, but I'll try to capture it in the github ticket at least for anyone who does want to try it.

fwiw, not talking about editors specifically, but while volunteering is great, and if somebody has time and motivation for it, I'm all for it, but I also wouldn't want to burn people out ("because otherwise we're gonna have to pay") and I'd rather lean towards paying someone to alleviate the pain.

Because there is money, and there could be more money if we put money in it.

(yeah it's all about money..)

MattJ, that's why I said it should be a github integration

why not use the fiscal hosting instead of hiring?

emus: something still has to hire someone :)

butbI thought no hiring is required

you put a budget

Budgets don't do work. You have to pay them to a human ;)

I can automate things with bash, but where are they running? in github actions or ?

I really hate working with proprietary CIs because they just change or go away at their whim

singpolyma: you psy the hours estimated

moparisthebest: any script you write for one CI will work in another generally. They're mostly the same

folks, its serious. And its not easy. I see that but we need to get different paths going here. I can only strongly encourage this. if people invest their hours vountarily and get tasks done, why not for some compensation...

singpolyma: nope they all have different variables they set with branch names, they all run in different contexts etc etc, it's a nightmare

moparisthebest: sure, so don't rely on any of that

I've moved stuff from Travis to sorucehut without any changes usually

Specifically the "push, wait for test to run, repush, repeat" dev cycle is the nightmare

For most things you should be able to dev and test locally

In any case, yes, go ahead and use bash... where they are running shouldn't be a concern

emus: the issue is that the XSF can't just randomly wire people money. They have to invoice first. And to send invoices you need to setup a legal entity that's allowed to do that. And then file taxes

That's a lot of work for someone who is employed and doesn't have such a legal entity setup

Oh glob the taxes! And the *reverse* VAT! 😱️

Daniel: really, you have to do all that where you are?

singpolyma: you don't?

Here people do freelance work without any special legal entity all the time

It's jus part of your personal income taxes

You can do the same in the UK

yeah Daniel, i dont think tis *that* complicated ..

if its in some normal range of income

It has a lot of drawbacks compared to setting up an entity, but plenty of people do it

It's not that complicated. But I can understand why someone doesn't want to deal with it

if it exceeds some amount it gets more complicated

i understand that its a lot of overhead for someone who does no contract work at all

and is just employee somewhere

I honestly have even done freelance without invoices, but I understand some kinds of entities need the invoices to pay so I write them when asked

there is some initial overhead

but if you hire someone who does that kind of work, then its not really more overhead for them

The hard part is finding the person and hiring them :)

Well that moves the overhead to the XSF.

And who's going to do that?

If you actually employ them I mean

No, don't do employer stuff for sure, especially cross border that's sometimes weird

Daniel i get your point, but i dont know how to solve it '...

but we need a solution