On 18/08/14 14:54, Brad Jorsch (Anomie) wrote: Or without knowing what version they were running on, or what specifically was the issue (different issues apply to different projects; for instance a quirk that would be a blocker on wikinews might be something we'd WANT for unnews on uncyclopedia)... The ratings also aren't necessarily for the things people might expect, either, especially if only a flat number is supplied: I expected 'rating' to be about the extension's effectiveness in production, but only 'usability' maybe covers that, despite not really applying to all extensions. And documentation quality should be pretty apparent if you're already on the extension documentation page on mw.org. Installation can be a massive pain in the arse but still very much worth it, especially as it is a one-time thing, so the real question may be is it worth it. I feel like we'd need context for the ratings to be at all useful. So I'd say the question should be asked - should these ratings be available? Going from there, that's also the discussion that would hone down what could make them truly valuable. -I

On 8/18/14, 8:47 AM, Chad wrote: Also: http://xkcd.com/937/ -- Legoktm

On Mon, Aug 18, 2014 at 12:08 PM, Mark A. Hershberger <mah(a)nichework.com> wrote: I see no discussion there. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation

I was meaning to comment on the overall GSoC proposal before the acceptance stage and didn't get a chance. Personally I don't think in it's current state/design it is overly suitable for deployment onto MediaWiki wiki as it will introduce a external factor on the page load for each visitor, although I haven't looked at the current privacy policy but it is generally considered a no-no for us. Also I do have concerns about the overall usefullness of the data and how it will correlate with the extensions, especially when it comes to matching to individual release versions and overall participation on data submission.

Probably the original IRC discussions. On 19 August 2014 17:22, Merlijn van Deen <valhallasw(a)arctus.nl> wrote:

Hi Jon, I am grateful to the wikimedia community for providing their responses about this project so there is nothing to be sorry about. I understand they have a lot of concerns to maintain the quality of data on the site. The rating system has been built on top of semantic mediawiki so this can be replicated anywhere on any wiki which has SMW installed along with a few other extensions. I really wish to see the project take shape and be helpful to mediawiki and for that i am willing to contribute beyond the gsoc period too. Jamie, the owner of wikiApiary thinks the same and he is willing to add more knowledge he farmed using data of extensions to mediawiki ( things like basket analysis; which extensions are used together, data from openhub.org on activity etc ) which in future may really enrich information on mediawiki. I hope this idea gets support for deployment. I believe it will open up a path for all such 3rd party sources who collect data in multiple forms, to process that data and enrich mediawiki with new knowledge and analytics in the future. Anyhow, I had a great time working on this. So thanks to everyone. :) On Wed, Aug 20, 2014 at 12:31 AM, Jon Robson <jdlrobson(a)gmail.com> wrote:

Is it really necessary for people to openly mock the work of a volunteer developer on the list? No wonder we have so few volunteer developers. On Mon, Aug 18, 2014 at 8:52 AM, Legoktm <legoktm.wikipedia(a)gmail.com> wrote:

Hi, One thing is clear, Aditya has a thick skin, which sadly still seems to be a quality required in many open source projects including ours. I wonder of many old-timers would enjoy the kind of reception he got here after introducing himself as a GSoC student -- even by people that know well what is to be an intern or a mentor. As a community, we should do better. To the point of the thread, we can have a discussion about extension ratings featured at mediawiki.org while wikiapiary.com enjoys the feature and users start using it there. We can even reject the feature altogether if this is what we want. This GSoC project, like all GSoC projects accepted, has explicitly avoided any deployment on Wikimedia servers lacking support from the related maintainers / community. Aditya just wants to get further with his project. Now, let's continue discussing user ratings as they could be implemented in a first iteration at mediawiki.org. Remember, the goal is to have a proper catalog of extensions, something that today we sorely miss (and thank Jamie for wikiapiary.com). For those interested in the process of proposing and accepting internship projects, here you have a post mortem of this specific case: On Tuesday, August 19, 2014, Strainu <strainu10(a)gmail.com> wrote: Perhaps, but what is the lesson we need to learn? Let's look at the history of this project: * The first idea was proposed in the "Possible projects" on February 2013 by Maria Miteva, as part of her FOSS OPW internship -- https://www.mediawiki.org/w/index.php?title=Mentorship_programs/Possible_pr… * Between March and April 2013, we fine tuned the proposal as "Research & propose a catalog of extensions", Yuri Katkov volunteered as mentor, and we moved it to the Featured section, and we created a report in Bugzilla -- https://www.mediawiki.org/w/index.php?title=Mentorship_programs%2FPossible_… & https://bugzilla.wikimedia.org/show_bug.cgi?id=46704 * During 2013, this project idea was featured in one GSoC round and two OPW rounds before, but candidates didn't pick it. * In January 2014, at the Architecture Summit, I had a chat with Mark Hersberger and Markus Glaser, aka MediaWiki release management team, where we decided to keep polishing this project at https://www.mediawiki.org/wiki/ExtensionGallery , and they volunteered as mentors. * This brought some discussion to the Bugzilla report and the wiki talk page. We also reached out to Jamie Thingelstad from Wikiapiari.com, a great service that we already link to in our extensions pages. * This time we got students interested. Aditya Chaturvedi was the first one reaching to us (as early as February) and he started drafting his proposal publicly by March -- https://www.mediawiki.org/wiki/User:Adi.iiita/Gsoc2014 -- https://lists.wikimedia.org/pipermail/wikitech-l/2014-March/075378.html * The fact of having students interested helped us narrowing the project. We decided to focus on implementing user ratings in Wikiapiary and finding a way to make that data exportable so mediawiki.org or whoever else could make use of it. We explicitly left out of the scope of the project any changes to mediawiki.org. * Aditya got some feedback during the review process but actually nothing (that I recall) criticizing the focus on user ratings. Then he was accepted. The he started to work under the supervision of Mark and Jamie. You can read his reports at https://www.mediawiki.org/wiki/User:Adi.iiita/Gsoc2014/Report ... And now Aditya is about to finish his GSoC project (looks like successfully), having followed our processes as they were designed and having accomplished the goals initially set. In the first place he deserves our congratulations and gratitude. The we can discuss what are the best next steps in the direction of improving mediawiki.org. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

On 20/08/14 11:48, Quim Gil wrote: The lesson to be learned here is not unlike what many teams could learn. When someone creates a product specifically for a certain group of users (in this case folks installing extensions) without actually knowing what is useful to them (never even mind 'important' at this stage), there is something seriously wrong with that process. This, however, doesn't particularly reflect on Aditya, who simply did the project as it was layed out; it was the folks guiding the project who should have started the process of actually talking to the users about this well before GSoC began, and continued it as part of the project itself. So here, the GSoC project needs to have been set up better. Simply put, you cannot reasonably expect random community members to carefully review every single proposal or new feature, so where feedback is needed, you need to go out and get it. The student is there to learn, and probably will not know that, and that's fine because it's supposed to be the sort of thing they're learning. The mentors may not know that either, if product design and engineering aren't their things, so that's not necessarily an issue either. But for projects that will affect people outside the project itself, for projects facing specific groups of users, someone along the line needs to know the importance of discussion, of determining the user/developer/whatever needs before engineering the product, and someone needs to give the guidance needed to make sure the relevant discussions happen. That's what needs to be addressed moving forward. -I

On Wednesday, August 20, 2014, Isarra Yos &lt;zhorishna(a)gmail.com <javascript:_e(%7B%7D,'cvml','zhorishna@gmail.com');>> wrote: This proposal was part of a research project done by Maria Miteva which involved a survey to a diverse collection of third party MediaWiki users. https://www.mediawiki.org/wiki/Third-party_MediaWiki_users_discussion/Summa… On the other hand, user ratings are a widespread feature. They are not THE solution for the current mess we have in the mediawiki.org Extensions namespace (call it a catalog would be too ambitious), but it looks like a reasonable candidate for the mix. Wikiapiary.com is part of the MediaWiki community and they have happily mentored, supported, and deployed this feature. Only for this, Aditya's GSoC can be considered a success. In order to move forward, we can discuss at different levels: * At a general level, which should be the priorities for mediawiki.org's gallery of extensions? This will allow us to define more tasks and projects for potential developers. https://www.mediawiki.org/wiki/ExtensionGallery * At the level of Aditya's project, do we want to try the integration of user ratings for extensions in mediawiki.org? Which requirements should the ratings shown meet? For the next step, should we focus on integrating Wikiapiary's data or should we come up with a solution for MW.O users to ate directly there? -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

On Wednesday, August 20, 2014, Legoktm &lt;legoktm.wikipedia(a)gmail.com&gt; wrote: I was in that room and I agree that defining and implementing this "gold standard" is a good idea. For what I recall, factors considered included objective facts like compatibility tested with Jenkins, support for LTS, etc. Still, I don't see this as a substitution of user feedack, with its potential drawbacks but also with the uniqueness that such human feedback provides. Whenever we have this type of discussion, Wordpress is mentioned as a good example of a catalog of plugins with information useful for Wordpress users (meaning Wordpress admins, just like in the case of MediaWiki). Look for instance http://wordpress.org/plugins/feedweb/ Requires: 3.0 or higher Compatible up to: 3.9.2 Last Updated: 2014-8-21 Downloads: 90,268 ((((This first block is quite objective)))) Ratings 4 stars 4.8 out of 5 stars 5 stars <http://wordpress.org/support/view/plugin-reviews/feedweb?filter=5> 24 4 stars <http://wordpress.org/support/view/plugin-reviews/feedweb?filter=4> 1 3 stars <http://wordpress.org/support/view/plugin-reviews/feedweb?filter=3> 0 2 stars <http://wordpress.org/support/view/plugin-reviews/feedweb?filter=2> 0 1 stars <http://wordpress.org/support/view/plugin-reviews/feedweb?filter=1> 1 ((((The ratings we are talking about, they show also the amount of votes, it does draw a picture about this plugin.)))) Author Feedweb Research <http://profiles.wordpress.org/feedweb/> 1 plugin ((((You can see how prolific this developer is, and check data & feedback on their other plugins, if you wish)))) Support 3 of 3 support threads in the last two months have been resolved. ((((We could apply something similar with Bugzilla/Phabricator, and perhaps even Flow one day)))) Got something to say? Need help? View support forum <http://wordpress.org/support/plugin/feedweb> Compatibility WordPress +Plugin = Works! 4 people say it works. 0 people say it's broken. ((((This little module is especially useful, as it attempts to tell you about specific combinations of Wordpress and plugin versions, according to other users -- imagine if Jenkins could vote there as well)))) Why not having both? -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

On 21 August 2014 08:58, Isarra Yos &lt;zhorishna(a)gmail.com&gt; wrote: Just thinking aloud, there are a few alternative mechanisms for helping users find extensions that are right for them: We could badge-ify installations based on some major re-users​ – "This extension is used by Wikia", "This extension is used by …" to help people get a feel for common big-wiki items, though that probably doesn't work for the majority of users who may have less specialised (or differently specialised) needs. We could have curated lists ("Good for internal corporate wikis"; "Good for managing multi-lingual user communities") that would guide users based on what they want to do, maybe with some basic roles pre-defined. We could have the "new", "new version released" and "popular" sections, of course, which are *de rigeur* in app stores and the like. This might be a bit too frothy for most users, though? Lots of possibilities! (BTW, some basic structured data about each extension would be great to expose for users for this purpose; maybe MediaWiki.org could be a potential future Wikibase target?) ​J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester