Thank you Brian for these comments. Details like this - practical,
specific, based-on-developer-experience suggestions, are GOLD and I'm
really hoping that you'll be able to provide more of them along the way.
Replies inline:
On 13 February 2015 at 16:42, Brian Wolff <bawolff(a)gmail.com> wrote:
First of all a nitpick:
" It is the only “integrated upload tool” for Wikimedia commons (aside
from the WMF-developed Upload Wizard)"
Technically you also have the original special:upload, and also that
mobile thing thats less popular.
That phrase came from the fact that the Upload Wizard and the GWT were the
only things listed in the "integrated" section of the page [[Commons:Upload
Tools]]. However, I see that as of a couple of weeks ago someone's added a
new item there too:
https://commons.wikimedia.org/w/index.php?title=Commons:Upload_tools&di…
I'll take your recommendation for how to better phrase this sentence to be
both factually accurate, but also to try to emphasise that this tool is
trying its best to be "of the system" rather than sitting outside of it.
---
One thing i would like to see in future gwt development is bringing it
further in line with mediawiki coding conventions. There are several parts
that do things differently than the normal mediawiki way, and also some
parts that duplicate mediawiki code, but is subtly different (e.g. some of
the sanitation code stands out in that regard). Ancedotally i believe this
inconsistency with MW core code conventions is significantly reducing the
amount of patches that interested unaffiliated developers would otherwise
contribute. I also think that more closely following mw core conventions
would make it easier for a wmf staff (or volunteer) who isnt previously
familar with the code to debug critical bugs in emergency situations (e.g.
things like the hhvm job runner bug).
Is it feasible for you to identify the specific parts that you're talking
about and add them to either the bug is on phabricator, or simply to email
them back to me and Dan? While noting that I'm not qualified enough to
know, I would think that "ensure consistency with MW core code conventions"
is an applicable thing to be added to very first item in this grant
proposal ("Identify major bugs in current system and fix"). While these are
not "bugs" per-se, if you can identify a hit-list of the places where the
current system diverges from standard practice, that would be very helpful.
One of the things I've already heard back from the WMF grants team is that
they'd like to see some demonstration of volunteer developer interest in
the GWT, and if addressing this point would help in that regard - that
would be excellent.
---
On the subject of code review, i believe a major contributing factor to
difficulties last time, was development outside of gerrit, and waiting
until the end to do code review. I strongly urge that all development be
done on wmf's version control (because people watch what happens on wmf
version control, and even if nobody is providing code review, they may
still point out things that could be significant problems later) . I know
first hand that getting code review, especially for non-wmf projects can be
extremely difficult. If at all possible, i strongly suggest code review be
done as incremently as possible.
I'll take any suggestions for how point might be integrated into the grant
application text, but suffice to say that I agree with you, and the plan is
always to try and do things 'by the book' and to 'bring people along for
the ride'. I think both we (europeana) and the WMF have lessons-learned
from the code-review experience last time. I'll let Dan respond with any
technical aspects to this point if he wishes?
Good luck with the grant. I really hope it goes
through, gwt is an
important project.
comments and endorsements posted to the bottom of the grant application are
always welcome! ;-P
--bawolff
_______________________________________________
Glamtools mailing list
Glamtools(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/glamtools