XSF Discussion - 2022-03-23

please consider not to split resources by forking again and again

lol

I'm generally pro forks, as long as the people doing the forking give proper credit (ahem Xabber-web) and ideally offer to contribute their enhancements back to the original project.

Forks can be useful to explore alternative approaches without disrupting the main project.

For forks that aren't aiming to be a hard fork that entirely diverges and turns into a different project (ie. ones that still track upstream and apply patches on top) I've found that the working on the upstream codebase and submitting patches there works really well. Then only apply them to the fork if the upstream project doesn't want it and isn't going to implement it.

Obviously if the upstream *does* merge your patches, then you get them back the next time you sync with upstream and you don't have to figure out how to pick them out of your project to submit a separate PR upstream, then merge the conflicts later, etc.

Yes, that's the ideal, but even hard forks are fine IMO. Sometimes the upstream/original project is very opinionated about how things should be done and the people doing the forking want to do things differently.

Ellenor Malik: what's your motivation?

primarily to learn python in the context of an extremely-complex project, secondarily to un-kill the traditional UI

So basically maintain 1.3 branch after the official support is over? :)

perhaps

I love forks. People eventually reach out to pay me to get an outdated fork back up-to-date.

People that realize this hire me to put non-proprietary changes in the upstream project. Win/win/win.

I did not wanted to state its bad to fork, but still review if supporting with this on the actual project could do it to. Guus: haha, thats the business perspective I assume :-)

That sounds like it will end up being a hard fork; you should update it to use aioxmpp so we can have clients that actually don't maintain their own library :)

(except I suspect at that point you might as well re-write it)

Emus: without a business perspective, I wouldn't be able to contribute to XMPP as much as I do.

Guus: No blame, is alright!

I wasn't really excusing myself, as I was trying to hint at "trying to make money" is a viable way to help develop the XMPP ecosystem. There are people that are volunteering amazing amounts of time and effort - which is great - but can't be done by many people. If, on the other hand, people can create a day-job from XMPP...

but yeah, waay off-topic. :)

in that regards (you are there already guus) if you offer any professional service: https://xmpp.work ✏

https://xmpp.work/all-listings/

@processone people: I recommend to maybe reshape the picture accordingly. Unfortunately the website does not handle it ✏

emus: I like how every single one is marked "popular" :)

Is that still maintained? Half of them you click on them and they're expired

(actually, more than half, all of them on the homepage are expired)

Hmm, more or less not. I think the website should be rebuild with hugo possibly but we have other works to do here currently

another question: is there a xep defining to favorise messages? Does it need a xep?

Define favorite messages? Do you mean pinning messages, or starring them? Are the favorited messages just for you, or can your contact see which messages of theirs you've favorited?

(I feel like there were XEPs for some of those depending on what you meant, but I can't remember)

Even if just bookmarking messages for yourself, it would need a xep for cross-client sync

just myself

emus, registration on xmpp.work isn't working right?

🤔️, can you create an issue?

where? ... wanna add me? maybe we are offtopic

on github, the xmpp.org repo simply

👌️

emus, no need for an issue ... tried again and seems to work ... maybe a browser hiccup 🙇️

ok

Would be great to show all service providers at once an randomized