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
