Community contributions to Element Web (Matrix client) are often not welcomed
Community contributions to Element Web (Matrix client) are often not welcomed
Checklist Tests written for new code (and old code if feasible) Linter and other CI checks pass Sign-off given on the changes (see CONTRIBUTING.md) Spec proposal Also has a compatibility mode ...
It seems that community contributions to Element Web (Matrix client) are often effectively rejected. For example, see:
- https://github.com/matrix-org/matrix-react-sdk/pull/9240
- https://github.com/matrix-org/matrix-react-sdk/pull/11078
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.
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.
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
What you might missed is that there are some PRs merged without adding or changing a spec (as a experimental function), others rejected after long silence. I agree completely with you about the group effort, but at first you would need to create a group at first, where you could discuss with the community (or notify them) what to be implemented, improved, etc. The team has lacked that kind of effort, and most of the communication take place privately.
I am not the author of the PR but sympathetic due to the effort the author has put to the PR for a year, which at first received reviews from a member which let the author expect that it was going to be accepted with necessary changes somehow, only to be notified by another member that the new spec change should cover the area the author has worked. If there had been a communication channel which worked between the team and the community, this kind of miscommunications should have not happened in the first place.
This PR is just an example; there are other cases where the volunteers were not included in the communication.
You probably would be able to see the same kind of problem more clearly on the issue for the notification sound improvement, which do not require a spec and the design team has said they were working on implementation several years ago and ignored comments for follow-ups since then, which is obviously not a healthy attitude toward the community.
- https://github.com/vector-im/element-web/issues/5891
- https://github.com/matrix-org/matrix-react-sdk/pull/4500#issuecomment-620942203 and https://github.com/vector-im/element-web/issues/5891#issuecomment-965030052
Still, Element is not a community-owned project after all, so it is it might make more sense to fork it as you said. like Forgejo was forked from Gitea. There is in fact a fork of Element, SchildiChat.
It seems that it is in fact how SchildiChat has forked from Element.
If i learned anything from my early contributions, it's checking the health of a project and attitude of its maintainers before spending anytime on that project.
Yes, I should have done that actually.
If you want to contribute to someone else's code, you should familiarise yourself with their values or plans before writing code. Can't expect them to accept any contribution without question.
Otherwise, fork the project and make your own version.
The point is that project pretends as if it would welcome any contribution, while there seems to be in fact a lot of rules and guidelines which are not shared with the community. I'm not saying it would be deceiving, though.
I have never really liked the idea of a web client for anything E2EE, the main reason I dislike them is that the web does not really offer a decent way to know if that code was modified server side and you being served a backdoored app. until the web adds a way to check the integrity of web applications I stay away from it
I once went into the Element support chat asking if it was possible to change my user name color, as I'm pretty closely identified to this username, and I despise the lime green it creates in that client. They said no, and typically I would expect to then be told, "but you can open a ticket in our tracker" or etc. Instead I was told, "use a different client if you want to change your username color (locally)."
Very weird experience.
Obviously there is a mistrust of the team toward the community, which makes them regard asking a question as attacking their product.
Firstly, I agree this is very shitty behaviour reminiscent of what a soon to be for profit company would do. See: Hashicorp Terraform.
But I've got to caution anyone against throwing in unsolicited pull requests. If the maintainers don't know about it they'll be upset. That being said the pull requests posted seem totally solicited and in fact led on by people before subsequently being torpedoed.
To me it shows well that the company thinks little of the importance of the communication between internal team members and external volunteers.
Unfortunately I don't think your experience is unique. I've seen several open source projects suffer from cliquey, protectionist behavior. I've been on a project where I was told by the primary developer to rebase my PR branch onto origin/main or it won't get looked at. By the time I've done that, that same developer's already pushed a commit directly to origin/main, and I'm no longer up-to-date.
Your case is pretty common with any project IME and it's not "cliquey" behavior. People really dont want to waste their time on something that's not ready to merge, and if the branch is pretty out of date it's probably not ready. I really doubt they'd complain about it being off by a commit or two, unless a merge conflict has come up since maybe.
Nah, we're talking a timescale of minutes here, a few hours at best. New feature, no conflicts, ready to merge. Fetch, rebase, push. Out of date almost immediately. Fetch new commit, rebase, push. Minutes later, out of date again.
See what I learned is, you can't outpace the sole project owner and principal developer, no matter how many other contributors the project has. Especially if he gets paid to work on the project full time. How do you compete with someone who has direct push access, commits every half hour, doesn't check PR's, and mandates rebases for fast-forward-only merges?
So my takeaway was, you don't. They're just not that into the feature, why should I be? Leave the branch exactly the way it is until someone asks for it to be made ready. They get 3 chances. If they don't merge it after asking for it 3 times, I tell them to checkout the branch themselves and take over. If I get code review feedback 3 times, I ask for peer programming. If they can't schedule it or don't want to, tell em check out the branch themselves and take over.
If they've got better things to do with their time, then you bet your sweet bippy I got better things to do with mine.
Matrix is open protocol, everybody is free to build their own clients. Maintainers of any one implementation are free to choose code to include in their project. And people can fork Element if they don't like the way it is going.
Maybe Element developers are not great in including external contribution… but still nothing else seems to implement Matrix that well.
No other client seems feature-complete. I wish I could use NeoChat instead of Matrix, but it still cannot even handle encrypted conversations properly. Are they rejecting contributions too?
No other client seems feature-complete.
In my opinion it is because the team which implements the features to Element, including what to implement and how to do it, substantially decides the protocol itself as well. You would easily identify who both implement the protocol and review PRs.
If you guys are by any chance interested in how members of the community responded, please check out the comments added after the PR was closed: https://github.com/matrix-org/matrix-react-sdk/pull/9240#issuecomment-1703060227 and below. You would be able to see the pent-up negativity toward the reluctant team communication. Check these two:
Not sure if Syphon rejects community contributions but I wish Syphon client got more love and attention. Syphon is more privacy focused and is written in Dart, allowing it to be compiled for desktop and mobile.
I have once tried Syphon but for an unknown reason it did not work for me really well.
