On 11/07/2013 11:59 AM, Pau Giner wrote:
"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.
If this is still open, please add me as a reviewer, then ping me if needed.
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.
Stuff that goes in core should generally be usable by more than one project (meaning e.g. no excessive hard-coding), but that doesn't mean there already needs to be more than one user. Once it's in core, naturally other users may need certain changes/generalizations made, and we can iterate.
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.
In general, just select a few people who are familiar with the area/type of code, and/or might be interested.
If you're not sure, there is a JavaScript group (just put JavaScript in the "Add Reviewer" box) that can be used when JS is involved.
We can easily make a similar CSS or Design one if desired. Don't use this for every change, since it is a bit spammy.
You still might need to ping people by email or IRC if a change has stalled out.
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).
A solution to this is to make an example usage, which depends on the change. For example, say you were adding the loader control in change A, but there were no uses in core yet (not even in A). You can make a simple change B that is based on (Gerrit shows this as Dependencies) it.
B doesn't need to be actually mergable. It can be marked Example or such. It will still be easy to check out for visual testing.
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).
Prototypes are essential, but eventually there is really no substitute for environments to actually run the code. These can be:
1. MediaWiki-Vagrant (really quite easy to set up, though it is true download time takes a while initially). 2. Labs - We should reduce obstacles to setting up a wiki on Labs, but in the meantime every time should have wikis to test. Does UX? 3. Any other local or other MW environment.
Ideally we should be able to provide a single source of truth that can be easily viewed, shared, and contributed to.
That single source of truth is the code in Gerrit. Everything else is a prototype. It may be a great prototype, or a great spec, but it's still a prototype.
The more replication and barriers, the hardest it will be to put a
quick iterative process to work.
Agreed, I hope the above is a starting point to reducing barriers.
Matt Flaschen