Technology

58061 readers

31 users here now

This is a most excellent place for technology news and articles.

Our Rules

Follow the lemmy.world rules.
Only tech related content.
Be excellent to each another!
Mod approved content bots can post up to 10 articles per day.
Threads asking for personal tech support may be deleted.
Politics threads may be removed.
No memes allowed as posts, OK to post as comments.
Only approved bots from the list below, to ask if your bot can be added please contact us.
Check for duplicates before posting, duplicates may be removed

Approved Bots

founded 1 year ago

MODERATORS

[email protected]

Community contributions to Element Web (Matrix client) are often not welcomed (github.com)

submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/[email protected]

20 comments fedilink hide all child comments

It seems that community contributions to Element Web (Matrix client) are often effectively rejected. For example, see:

There are also many other PRs for Element Web/Desktop which have not gotten a review in a timely manner (see here). The request to improve the ~~terrible~~ notification sound has been there since 2017, and though several PRs have been submitted to improve it, they have been either ignored or rejected for an unknown reason (there should be an epic project going on which should make the six-year-wait legitimate).

When it comes to development of Element, there is a lot of unspoken, unwritten, internally shared rules among the internal team members. Your PR will be effectively rejected even if it works, unless it aligns with their goals, which you cannot know before submitting a PR.

It should be well noted that there is a clear and strict division between the internal paid workers and external volunteer developers who essentially provide the team free labor. The exclusive attitude of the team behind Element has discouraged the latter from contributing to the project. I myself have been one of the active localization volunteers, but I stopped contributing after I realized it has been free labor.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 39 points 1 year ago* (last edited 1 year ago) (3 children)

There's a difference between contributing self-contained code, and changing a protocol that has to live forever. The receiving organization is making a commitment to honor all protocol changes, for very long time for compatibility reasons. They're allowed to have opinions about that. I'm sorry it didn't work out for these people, but somebody has to own the protocol, and the API, and the risk surface.

The way it is implemented, custom emoji are sent as short codes only with the rendering happening on the receiving side. This creates a rather large vector for abuse and we're not gonna accept it in this form.

Separately from that, the Spec Core Team expects to land custom emoji / sticker packs in Matrix v1.9 which is due in November. Given how close this is, we think that it's worth blocking this contribution to align on a proper solution on the spec level. I'd encourage you to engage with the spec process on the various MSCs around this feature to help influence the decision making.

This is just how large software works. You got to work with a large group. You can't make sweeping changes on your own. It's slow, it's cumbersome, but hopefully group effort is greater than the sum of its parts.

I don't see anything here that's unreasonable on behalf of element

I think the main difference between community contributors and paid developers is just the timeline they're looking at. How far into the future are they looking, are they looking at technical debt, are they seeing this as some burden the organization has to carry. It's a subtle difference, but it does change how people react and accept new things.

[–] [email protected] 7 points 1 year ago (2 children)

I should add nothing's preventing people from forking the code base and maintaining their own independent distribution. Much like there's multiple versions of new pipe both with and without sponsor block.

So it might be frustrating that changes aren't accepted, but because it's open source those changes can live on, and if you get enough people to adopt your fork, you can become the de facto standard. That's kind of democratic software

load more comments (1 replies)