Last modified: 2014-09-23 20:00:33 UTC
Extensions on mediawiki.org are not very well organized and finding the right extension is often difficult. The community needs better management of extension pages with categorization, ratings on code quality, security, usefulness, ease of use, etc. Good extensions should be given more visibility. “Featured extensions” similar to featured articles could be introduced. The compatibility of extensions with different MediaWiki versions should be clearly displayed and possibly compatibility testing should be automated. In terms of implementation, some suggest using SMW for the organization of the data and Article Feedback for rating. Developers should be able to add a PayPal account link to fund the maintenance of their extensions. Note: This project should probably be implemented by someone with a lot of experience with MediaWiki. An intern could work on pre-implementation work such as collection of requirements and detailed design/specification. This is a proposal made by Mariya Miteva at http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#A_proper_catalog_of_extensions while she was working on https://www.mediawiki.org/wiki/Third-party_MediaWiki_users_discussion as part of her Outreach Program for Woman internship. Recovering it here to see if there is community consensus on the need and we can shape a proposal for a volunteer.
+1 totally necessary.
[Please don't add "+1" comments in Bugzilla, but feel free to vote. Thanks.] > extension pages with categorization, ratings on code quality, security, usefulness, ease of use, etc. Not sure how to rate code quality but you could easily gather data on code activity and set that in relation to size of codebase. On the general idea: I'd love to have that machine-readable, so you could reuse the information in other places.
This seems like it would be really great. For meta-points, you could make it into an extension *for* MediaWiki.org :P.
(In reply to comment #2) > [Please don't add "+1" comments in Bugzilla, but feel free to vote. Thanks.] > > Is voting now actually used and/or useful, then?
(In reply to comment #4) > (In reply to comment #2) > > [Please don't add "+1" comments in Bugzilla, but feel free to vote. Thanks.] > > > > > Is voting now actually used and/or useful, then? No, people just use it to track bugs without using the cc feature *sigh*
Yuri Katkov has volunteered to be mentor for this project, which is now featured for Outreach Program for Women: Research & propose a catalog of extensions http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Research_.26_propose_a_catalog_of_extensions
I don't have any issue with +1 comments. For what it's worth, I agree that a better extension catalog would be nice. Quim: [[mw:Extension Matrix]] already exists, but I understand and appreciate that you want something better. Given the complexity here, can you please start an [[mw:RFC]] and cross-reference this bug's URL field? A wiki page is much better than a bug report for working on this at this stage, I think.
I don't have the intention to start a proposal myself. I'm just doing te homework to feature this project idea to Outreach Program for Woman candidates or anybody else willing to work on this. But good point: whoever takes this task will need to go through the RFC process.
I'll assign this bug to myself
Is there an interest in proposing this project for Outreach Program for Women? If so, and if there at least one mentor for it. please move it to the "Featured projects" section. This way it will be automatically transcluded in https://www.mediawiki.org/wiki/Outreach_Program_for_Women/Round_7 Thank you!
Hi, this project is still listed at https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Research_.26_propose_a_catalog_of_extensions Should this project be still listed in that page? If not, please remove it. If it still makes sense, then it could be moved to the "Featured projects" section if it has community support and mentors.
After a chat with Markus Glaser, Mark Hersberger, and Jared Zimmerman at the Architecture Summit, we have decided to create a wiki page to define the specifications of this project. Your ideas and feedback are welcome: https://www.mediawiki.org/wiki/ExtensionGallery While we have no idea where the resources to develop this project will come from, we agree about its importance, and we think that defining a plan is the obvious first step. Markus & Mark will lead this discussion as part of their efforts improving MediaWiki as a product for third parties.
/s/PayPal/non-evil-things How about bitcoin and services such as http://gittip.com/ and http://flattr.com/ ?
I would love to volunteer WikiApiary to help with this effort. We already have an index of 3,876 extensions on 8,373 websites. I've got a program that will do "basket analysis" of extensions to determined most commonly installed next to each other. I’m now pulling in license information and allow connecting to Composer packages. Extensions already can be tagged. I would love to be able to vote on them, but there is no great voting extension for MediaWiki that fits this use case. https://wikiapiary.com/wiki/Extension:Main_Page I'd be happy to host bots that analyze this data, store cumulative information and then feed it via bot into MediaWiki.org. All of this data is already completely exposed via the Semantic MediaWiki Ask API.
Jamie, Thank you we'd love to have you involved in this project.
We are featuring https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Catalogue_for_MediaWiki_extensions as a GSoC / OPW project idea, and apparently there is at least one candidate interested. However, looking at this report and looking at [[mw:ExtensionGallery]] there doesn't seem to be a clear plan. This and the fact that the project might look straightforward to a newcomer might pose a serious risk to whoever takes it, mentors included. Mark & Markus, please define clearly the scope of the project offered to students. See [[mw:Mentorship_programs/Lessons_learned]] for advice on well defined projects and calculating a reasonable amount of work for a new contributor.
Also, ideally GSoC projects are more about developing generic features than about solving a specific problem for a single site. What about an extension to handle pages in a specific namespace that users can publish "ratings and reviews"? This would be the basis for the catalog of extensions in mediawiki.org, but it could also be used by other sites for other purposes. I'm just improvising with this example. You see what I mean.
I agree with Quim and I'll say more, in its present state the proposed project is certain to fail. We've already tried twice in the past (2010 and 2011): "Extension management platform: not co-ordinated with WMF ops, too hard for GSoC", "Extension Release Management: too hard, student's personal problems" (quoting https://www.mediawiki.org/wiki/User:MaxSem/GSoC_analysis ). The current proposal is slightly different but poses the same issues. I'd say to abandon any idea that requires WMF involvement and focus on something that can be used on WikiApiary, building upon an existing extension; if things work out there, maybe in a year or two this will land on mediawiki.org or similar, as opposed to complete failures that we keep regretting for half a decade or more. Probably the best option are existing rating extensions, but they need some exploration http://lists.wikimedia.org/pipermail/mediawiki-l/2014-February/042549.html ; I think the only one with some usage and semi-active maintainers is VoteNY?
I agree. Improvements in this area are VERY welcome, but let's take a feasible bite for the student and our projects. An extension that would be useful today to Wikiapiary and tomorrow to mediawiki.org sounds like a very good plan: it would have more chances of being useful to more MediaWiki installations, and we would have more chances of getting mentoring help from Jamie Thingelstad (I guess). Also, Wikimedia is already an umbrella of MediaWiki projects in GSoC and other outreach programs. Having a first collaboration with a new stakeholder (Wikiapiary) would be already a success. PS: all the better if such project could generate feeds with interesting data that could be used in mediawiki.org pages. Followoing Nemo's example, that could be e.g. most recent extensions rated, last rates for a specific extension, etc.
Nemo, Quim, Thanks for your feedback so far. I'm going to work with the student on this and get Aditya to focus on working with WikiApiary on this.
Also, I just got buy in from Jamie Thingelstad. Cooking with gas, now!
Great, thanks Jamie. I suggest to edit the "Possible projects" page to reflect recent updates.
https://wikiapiary.com/wiki/WikiApiary_enhancements Will update possible projects page.
Let me note that, if some off-the-shelf extensions were added to mediawiki.org (Semantic MediaWiki, Semantic Drilldown, possibly Semantic Ratings and Semantic Forms), I think the basic idea of making an extension directory that's searchable via various facets could be accomplished relatively quickly - maybe even in just a few days. There's certainly no shortage of people from the SMW community who would be willing to help out with this task, if the tools became available. Nemo - those previous GSoC projects are mostly irrelevant here. They had to do with managing extensions on one's wiki, whereas this project is about managing *information about* extensions - a much simpler task.
(In reply to Yaron Koren from comment #24) > Nemo - those previous GSoC projects are mostly irrelevant here. They had to > do with managing extensions on one's wiki, whereas this project is about > managing *information about* extensions - a much simpler task. Well, if that's the case it's totally unclear in their project descriptions (as is often the case with projects which didn't go well).
I forgot to add that it would be great to add in some of the WikiApiary information, like usage statistics - and that it might be possible to do this with the External Data extension.
The discussion of enabling SemanticMediaWiki in mediawiki.org is very old, and we can't make a GSoC project depend on its resolution. Also, as said in Comment #17, a GSoC can't be about implementing a catalog of extensions in mediawiki.org, it must be a more generic software development project. GSoC/OPW participants have their deadline very soon, let's focus in discussing their proposals (by default in their wiki pages). Here is one: https://www.mediawiki.org/wiki/User:Pubudu538/Gsoc_2014/Application
I agree with you fully, and for that reason - and I apologize for the harshness of this statement - I personally don't think this task makes sense for a GSoC or OPW project.
Hie, I have been working on the proposal of this project for quite sometime to clear out the scope and deliverable. Please have a look. https://www.mediawiki.org/wiki/User:Adi.iiita/Gsoc2014 Also, the public URL for the full proposal is given (google doc link). Please go through that too and let me know what you think.
I don't know if it is too late to bring in some feedback, in any case my recommendation would be: do it as generic as possible. There are many other projects that can benefit from displaying a "gallery of pages in a category". For instance IdeaLab already uses a gallery, it would be even better if an extension could manage it, instead of having it hardcoded. https://meta.wikimedia.org/wiki/Grants:IdeaLab/Ideas#idealab-new
(Sorry only reading the comments here for so long. As a potential mentor for this project, I should have been more active here.) (In reply to dacuetu from comment #30) > I don't know if it is too late to bring in some feedback, in any case my > recommendation would be: do it as generic as possible. I agree, this should be as generic as possible. Still, the goal here is to get extensions rated for usefulness, bugginess, ease of setup, etc. and get those ratings onto MW.o. That requires design and some social cues that get people to rate extensions that they use. As Yaron points out most of the tools, to do the rating already exist. To this end, what results from this project will be probably most useful to those like Idealab as an instance of how to use the extension. (In reply to Yaron Koren from comment #24) > I think the basic idea of making an extension > directory that's searchable via various facets could be accomplished > relatively quickly - maybe even in just a few days. There's certainly no > shortage of people from the SMW community who would be willing to help out > with this task, if the tools became available. Since WikiApiary already has been set up with SMW and already has the information about extensions, we're going to be working with Jamie to make the rating and collection of extensions happen there. We plan on using a 'bot (if need be) to copy the information to MW.o Getting new software (SMW!) deployed on the WMF infrastructure is too big an impediment. WikiApiary is already proving to be an invaluble tool for those of us with experience. This project will help us expose that usefulness to newer users as well.
> Getting new software (SMW!) deployed on the WMF infrastructure is too big an > impediment. Is that really the case? I certainly hope not. SMW (or, should I say, "SMW!") is already in use on one WMF wiki - wikitech.wikimedia.org - as well as on a wiki heavily used by the MediaWiki project, translatewiki.net. Perhaps it would just take a champion of the software on the inside to convince the powers that be to allow it on mediawiki.org as well? I'm not aware of any strong resistance to the use of Semantic MediaWiki on the non-"core" sites, like mediawiki.org - just the usual forces of apathy.
(CCing Lydia because I'm mentioning the d: word below) :) SHORT TERM, CRITICAL TO GSoC 2014 PROJECTS Let's agree that any plan related with GSoC 2014 is going to be based on an implementation in Wikiapiary capable of feeding back to mediawiki.org. What is more, the definition of a minimum viable product can focus on Wikiapiary alone. I'd rather see a good and inspiring implementation exclusively in Wikiapiary than a half-backed solution trying to make equally (un)happy both sites. LONG TERM, TO BE ONLY REMOTELY CONSIDERED BY GSOC 2014 PROJECTS SMW in mediawiki.org. Based on the history of this old discussion reactivated every now and then, I don't see it happening. I don't even have an own opinion; I'm talking about probability. Now, let me share a question / thought: has anybody discussed the possibility of creating Wikidata items for extensions, after defining a set of properties to describe them? Linking those Wikidata items to mediawiki.org extension pages, and then playing with templates and what not to keep the semantic data up to date (version number, last release, dependencies, compatible with MediaWiki releases...)? Then play with templates, queries and visualizations to create all kinds of useful output, from structured extension pages to a proper and robust map of extensions. I mean, whether it is done with SMW or Wikidata, a common and most important aspect of the work is how to define semantically an extension, which data we want to display and we can update as automatically or as crowdsourced as possible, and how to migrate the plaintext information we currently have to a semantic container.
This seems possible with Wikidata in the future. What is missing is at least: * access to Wikidata for mediawiki.org * extended quantities datatype * access arbitrary items * queries * visualizations All on the development plan at https://www.wikidata.org/wiki/Wikidata:Development_plan
(In reply to Yaron Koren from comment #32) > Perhaps it would just take a champion of the software on the inside to > convince the powers that be to allow it on mediawiki.org as well? A GSOC student is, by definition, not "on the inside". Thus, Quim's statement: (In reply to Quim Gil from comment #33) > Let's agree that any plan related with GSoC 2014 is going to be based on an > implementation in Wikiapiary capable of feeding back to mediawiki.org. What > is more, the definition of a minimum viable product can focus on Wikiapiary > alone. makes a lot of sense. If this can be made to work with Wikidata, even better.
For the record, the installation of SMW on Wikimedia Wikis is tracked on https://bugzilla.wikimedia.org/show_bug.cgi?id=8390
> SMW in mediawiki.org. Based on the history of this old discussion reactivated > every now and then, I don't see it happening. Quim - I think you're misunderstanding the history. A few SMW developers and users have brought up the idea of installing SMW on mediawiki.org several times over the past, say, six years. There's certainly never been a concerted effort on anyone's part - and certainly not from anyone who works for the WMF - to get it installed on mediawiki.org. It may or may not be easy to accomplish - I wouldn't know; as far as I know, it's never been tried. Helder - I think the problem with that bug report/feature request is that it covers both core WMF sites like Wikipedia and non-core sites like mediawiki.org - two types of sites that have almost nothing in common, other than the fact that they both run on MediaWiki.
(In reply to Yaron Koren from comment #37) > Quim - I think you're misunderstanding the history. I'm just being pragmatic, if it didn't happen in six years it is unlikely that it will happen in the next six months. This is why I'm insisting in not having this factor in the picture of this GSoC project, while still seeing a point in helping Wikiapiary (and indirectly mediawiki.org) with a GSoC project in 2014. > Helder - I think the problem with that bug report/feature request is that it > covers both core WMF sites like Wikipedia and non-core sites like > mediawiki.org - two types of sites that have almost nothing in common, other > than the fact that they both run on MediaWiki. If you want to request SMW in mediawiki.org then please open a new report. Let's focus here and now on the proposals that two students and three mentors are pushing these days related to "a catalog of MediaWiki extensions". We have a few days to decide whether any of these proposals is accepted.
> I'm just being pragmatic, if it didn't happen in six years it is unlikely that > it will happen in the next six months. Well, if anyone had really made an effort to accomplish it in the last six years, that argument probably would have had more validity. :) > We have a few days to decide whether any of these proposals is accepted. Sure. I've already expressed my opinion on the matter.
Hi, I have been working on the proposal for this project for some while. The idea was featured among the first 10-12 ideas for GSOC 2014 by wikimedia and also in the earlier programs (comment 18) so I believe this project is an important one for the community. Though I believe the discussion has brought out clearly that the project shouldn't involve WMF, and thus is more suitable to involve wikiapiary and help MW.o with data push back but I think we should now formalize on how this project can be made "as generic as possible" and within the scope of GSOC with a clear consensus. However, I think from the very beginning i.e right from the title of this project, it reflects to be something specific to MW.o and I guess, the final aim is the same but for the GSOC project scope should help to push the initial steps of this long waited project. Because the time is short, I shall be really grateful if you all can suggest some specifics on what should be done on this project and how, so that it falls within the scope of Gsoc and also help push the initial steps for the major project of catalogue. I have created a proposal. Please look at that also. Hope it helps. https://www.mediawiki.org/wiki/User:Adi.iiita/Gsoc2014 Details: https://docs.google.com/document/d/1zuWhi0Op7yoRW5xjryco7e6xOWuT2E4bPRTJAbwf8Dc/edit?usp=sharing
Aditya's mentors have considered this project PASSED. Still, we are missing the required final blog post and, in general, an idea of the next steps in order to benefit from the results of this project. I'm removing https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Catalogue_for_MediaWiki_extensions from the list of featured projects. If you want to continue this work through another project, please define it and obtain community consensus. A new round of FOSS OPW is just starting.
(In reply to Quim Gil from comment #41) > Still, we are missing > the required final blog post and, in general, an idea of the next steps in > order to benefit from the results of this project. This is coming. We have one queued up, but we're rewriting this. Is posting this on my own blog ok?
http://hexmode.com/2014/09/summer-of-code/ -- post on my blog.
