You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When it comes to development of what is maintained by matrix-org foundation (not vector-im), I feel it is important to open discussions to the community. Currently it seems (because it cannot be proved independently) that the large part of the decision making (related to matrix-react-sdk for example) occurs on private Matrix rooms, closed Figma projects, etc., as discussions on #element-dev:matrix.org between the employees are sparse compared with the amount of development work.
I am not suggesting that every communication should be published. I also understand the core of Matrix is the specifications and discussions related to them are open at https://github.com/matrix-org/matrix-spec-proposals, but I feel that discussions related to how those specs are actually implemented are not as open or transparent.
I believe what the Foundation manages should be not only provided (like weekly blog update) but also be opened to the community in some way. Otherwise, the basic mindset would be something like that employees decide how to code and those who are not employees are allowed to code in that way. I would not object it, because the Foundation is the owner and members who constitute the Foundation should decide how to manage the project, but I would not believe that that kind of mindset would help to increase engagement by independent developers, either (although I do not have an academic evidence which supports the thesis that opening discussion to the community would accelerate software development). In some cases that kind of model might result in quite negative reactions by the community which can be seen here related to the custom notification sound implementation and here related to sending GIF. Please note that on the first case a PR was submitted by a community member, only to be rejected by the design team on the ground the that team would implement it by themselves, which has not happened yet since then.
I've had a conversation with Mathew Hodgson about it where he said the core team is busy and that "we welcome community contributions". Which is totally fair enough.
However, to now have issues like this effectively shut down with an over-complication and "the core team has to do it" at some possible unspecified time in the future is not great and counter to an open source ethos.
(emphasis mine)
I think this kind of reaction is a natural result of the discussions being closed.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
When it comes to development of what is maintained by
matrix-org
foundation (notvector-im
), I feel it is important to open discussions to the community. Currently it seems (because it cannot be proved independently) that the large part of the decision making (related tomatrix-react-sdk
for example) occurs on private Matrix rooms, closed Figma projects, etc., as discussions on #element-dev:matrix.org between the employees are sparse compared with the amount of development work.I am not suggesting that every communication should be published. I also understand the core of Matrix is the specifications and discussions related to them are open at https://github.com/matrix-org/matrix-spec-proposals, but I feel that discussions related to how those specs are actually implemented are not as open or transparent.
I believe what the Foundation manages should be not only provided (like weekly blog update) but also be opened to the community in some way. Otherwise, the basic mindset would be something like that employees decide how to code and those who are not employees are allowed to code in that way. I would not object it, because the Foundation is the owner and members who constitute the Foundation should decide how to manage the project, but I would not believe that that kind of mindset would help to increase engagement by independent developers, either (although I do not have an academic evidence which supports the thesis that opening discussion to the community would accelerate software development). In some cases that kind of model might result in quite negative reactions by the community which can be seen here related to the custom notification sound implementation and here related to sending GIF. Please note that on the first case a PR was submitted by a community member, only to be rejected by the design team on the ground the that team would implement it by themselves, which has not happened yet since then.
For me, this post seems reasonable: #321 (comment)
(emphasis mine)
I think this kind of reaction is a natural result of the discussions being closed.
Beta Was this translation helpful? Give feedback.
All reactions