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@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&dif...
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/glamtools