4 ms·
Thanks oelmekki, Highly appreciate the feedback--critique is valued, and we welcome hearing it publicly. It benefits Mattermost to have more people with deep
by it33 10y ago
Thanks oelmekki,
Highly appreciate the feedback--critique is valued, and we welcome hearing it publicly.
It benefits Mattermost to have more people with deep React experience looking over the project and suggesting changes.
One example is the discussion that influenced us to adopt React Router: https://github.com/mattermost/platform/issues/790 https://github.com/mattermost/platform/issues/790
Mattermost started in the early days of React and you're right not all the patterns were in place from the start--and you've pointed out areas we know we want to re-write.
We're doing this by starting fresh with new React Native apps using Redux: https://github.com/mattermost/mattermost-mobile https://github.com/mattermost/mattermost-mobile
The goal is to create a model for the future with React and Redux, and move that back into the server.
Would you be interested in dropping by our Developer channel some time (https://pre-release.mattermost.com/core/channels/developers https://pre-release.mattermost.com/core/channels/developers) and maybe just hanging out with us and sharing more of your thoughts?
For example, how would you break the re-write into parts, and prioritize?
How might we organize tickets for people to help?
On Wednesdays at 10am California time we have open developer meetings via Hangouts if you're up for speaking in person (or any time really, we're always looking for feedback).
Just a thought,
What I would note is that we have significant test coverage on the Mattermost server and hundreds of manual tests run for each release, so the quality of the end product is generally high, even if the React code isn't pristine.
I would say the Mattermost project is closer to the beginning than it is to the end. Significant refactoring is on our roadmap, and we'd highly welcome help.
- oelmekki 10y agoSure! I'm already under contract half time, and I work on my own company for like two full time, so I can't be a big contributor, but I contribute here and there to open source projects, so I can look around from time to time. > For example, how would you break the re-write into parts, and prioritize? I would probably do it component per component, factoring out complexity one method at a time. I avoid "big rewrites", aka v2 or whatever, because I've seen too many startups doing that to disastrous consequences (typically: a whole dev team not releasing anything for like a year, and a "new" app that is at the end not better than the previous one). Not really a surprise: v1s are iterated on and always keep track of reality, by releasing often - which v2s never do, they just try to bring everything at once. > How might we organize tickets for people to help? I guess people at Gitlab have way better ideas than me, given how successful they've been at that :) I see you already have a "help wanted" section, that's probably the most important, so contributors can quickly spot low hanging fruits and help a bit.
- sokoloff 10y agoVery classy and open-minded response and attitude.