I have once tried Syphon but for an unknown reason it did not work for me really well.
Obviously there is a mistrust of the team toward the community, which makes them regard asking a question as attacking their product.
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:
To me it shows well that the company thinks little of the importance of the communication between internal team members and external volunteers.
It seems that it is in fact how SchildiChat has forked from Element.
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.
Yes, I should have done that actually.
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.
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.
Where the hell are Western feminists?? 🤦
Fax machines are one of the main ways of communications there. I guess floppy disks are indeed partly used at municipal offices yet.
Unless the governments would change radically how they see FOSS from a way of reducing money cost…
Japanese local governments, let alone the central one, still have almost zero knowledge about the value of maintaining infrastructure which they should have full control. Virtually even discourses about it do not exist yet. Huge difference from the European governments.
Japanese local governments, let alone the central one, still have almost zero knowledge about the value of maintaining infrastructure which they should have full control. Virtually even discourses about it do not exist yet. Huge difference between the European governments.