I propose we try this proposal in code, on real process flows that actually exists and inform our decisions of what to change and how to change it on actual user feedback and testing.
I totally agree with this. However, in my opinion there are some aspects that we need to support better for this to work in practice:
- Make it easier to contribute from projects. With previous incarnations of Agora I tried to contribute changes: a loading indicator control (GitHub pull request that I later converted into Gerrit patchset when the GitHub repo was deprecated) and a spacing fix. Nothing got merged nor requests for improvement were made. I think this is due to:
- The fact that this involves merging into core, so it makes it hard to accept a component that works for a specific project and will become more generic in the future by iterating.
- The lack of a clear discussion process: Since this involved different roles and teams it is hard to solve, but we need clarity on who should contributors ask to reviewing and approve those changes.
- The difficulty to review UI code without context. Even for a simple change of colour or padding, the person reviewing the change needs to answers many questions (how dis it look before? how does it look now?, is it affecting the look of any other component anywhere else in the system?) which require a lot of work to answer. Make it easy to view the UI components would facilitate this process (which leads to the next point).
- Make it easy to check the current status. If the current state of the style is embedded into a specific project, or a local installation of Mediawiki is needed, we are putting too much barriers for most of our users (think on the steps that a volunteer designer at a Hackathon should do to view the Agora buttons and suggest a different tone of blue). Ideally we should be able to provide a single source of truth that can be easily viewed, shared, and contributed to. The more replication and barriers, the hardest it will be to put a quick iterative process to work.
Don't take the above as a complaint. Making a process that involves many teams and roles work fluently is really hard. I just wanted to share some of the issues I found when tried to go through this process in previous attempts so that we can learn from previous experiences.
Pau