It's time to start defining what we want our Google Summer of Code to be all about. Let's look at the ideas we are proposing to potential students:
https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects
Many of the ideas listed there are too generic ("Write an extension"), improvements of existing features ("Improve Extension:CSS") or work-in-progress tasks ("Fix Parsoid bugs"). Many others are not directly related with development, and therefore not suitable either for GSOC.
After this filtering, we seem to be left with:
* Article evolution playback tool idea * An easy way to share wiki content on social media services * Write an extension to support XML Sitemaps without using command line * Extension:OEmbedProvider * Add support for x3d 3D files to MediaWiki * Allow smoother and easier Wikimedia Commons pictures discovery * Build an interwiki notifications framework and implement it for InstantCommons * Automatic category redirects
(If you think your project should also be considered here please speak up!)
Most of these projects seem to be extension (and PHP?) centric. Can we have more diversity? Maybe gadgets and templates are too simple for a GSOC project? What about the mobile front? Do we have skin development projects that could make it here? Anything in the DevOps area? Anything the MediaWiki core maintainers would like to see happening?
It would be also nice to have more candidates benefiting specific Wikimedia projects. Beyond Wikipedia, we have several proposals related to Commons. Wikidata seems to be joining soon. What else? Could this be a chance to help Wiktionary, Wikibooks or any other project with specific needs craving for tech attention?
Also to the many students that have already showed their interest: feel free pushing your project ideas now!
Would there be interest in integrating the work on authorship computation? This would not be an extension; it would be ... server-side development that could fit well with a Summer of Code?
Luca
On Wed, Mar 20, 2013 at 4:43 PM, Quim Gil qgil@wikimedia.org wrote:
It's time to start defining what we want our Google Summer of Code to be all about. Let's look at the ideas we are proposing to potential students:
https://www.mediawiki.org/**wiki/Mentorship_programs/**Possible_projectshttps://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects
Many of the ideas listed there are too generic ("Write an extension"), improvements of existing features ("Improve Extension:CSS") or work-in-progress tasks ("Fix Parsoid bugs"). Many others are not directly related with development, and therefore not suitable either for GSOC.
After this filtering, we seem to be left with:
- Article evolution playback tool idea
- An easy way to share wiki content on social media services
- Write an extension to support XML Sitemaps without using command line
- Extension:OEmbedProvider
- Add support for x3d 3D files to MediaWiki
- Allow smoother and easier Wikimedia Commons pictures discovery
- Build an interwiki notifications framework and implement it for
InstantCommons
- Automatic category redirects
(If you think your project should also be considered here please speak up!)
Most of these projects seem to be extension (and PHP?) centric. Can we have more diversity? Maybe gadgets and templates are too simple for a GSOC project? What about the mobile front? Do we have skin development projects that could make it here? Anything in the DevOps area? Anything the MediaWiki core maintainers would like to see happening?
It would be also nice to have more candidates benefiting specific Wikimedia projects. Beyond Wikipedia, we have several proposals related to Commons. Wikidata seems to be joining soon. What else? Could this be a chance to help Wiktionary, Wikibooks or any other project with specific needs craving for tech attention?
Also to the many students that have already showed their interest: feel free pushing your project ideas now!
-- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgilhttp://www.mediawiki.org/wiki/User:Qgil
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
Thank you for the feedback!
Brion & co, I have tried to distill the essence of your comments and write it down as generic guidelines at
https://www.mediawiki.org/wiki/Summer_of_Code_2013#Project_ideas
On 03/20/2013 04:53 PM, Luca de Alfaro wrote:
Would there be interest in integrating the work on authorship computation? This would not be an extension; it would be ... server-side development that could fit well with a Summer of Code?
I can't say much since I'm not aware of that project, but what matters is to list it with a good description at https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects
Hi!
I think will be good idea to direct some of Google Summer of Code participants energy to help Wikidata which misses many must-be features. Some of them like support for projects other then Wikipedia is postponed to next years, but something tells me that it may be clone of existing functionality in most cases except one-to-multiple links in Wikisource :-)
Eugene.
On Wed, Mar 20, 2013 at 4:43 PM, Quim Gil qgil@wikimedia.org wrote:
It's time to start defining what we want our Google Summer of Code to be all about. Let's look at the ideas we are proposing to potential students:
https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects
Many of the ideas listed there are too generic ("Write an extension"), improvements of existing features ("Improve Extension:CSS") or work-in-progress tasks ("Fix Parsoid bugs"). Many others are not directly related with development, and therefore not suitable either for GSOC.
After this filtering, we seem to be left with:
- Article evolution playback tool idea
- An easy way to share wiki content on social media services
- Write an extension to support XML Sitemaps without using command line
- Extension:OEmbedProvider
- Add support for x3d 3D files to MediaWiki
- Allow smoother and easier Wikimedia Commons pictures discovery
- Build an interwiki notifications framework and implement it for
InstantCommons
- Automatic category redirects
(If you think your project should also be considered here please speak up!)
Most of these projects seem to be extension (and PHP?) centric. Can we have more diversity? Maybe gadgets and templates are too simple for a GSOC project? What about the mobile front? Do we have skin development projects that could make it here? Anything in the DevOps area? Anything the MediaWiki core maintainers would like to see happening?
It would be also nice to have more candidates benefiting specific Wikimedia projects. Beyond Wikipedia, we have several proposals related to Commons. Wikidata seems to be joining soon. What else? Could this be a chance to help Wiktionary, Wikibooks or any other project with specific needs craving for tech attention?
Also to the many students that have already showed their interest: feel free pushing your project ideas now!
-- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Mar 21, 2013 at 1:04 AM, Eugene Zelenko eugene.zelenko@gmail.com wrote:
Hi!
I think will be good idea to direct some of Google Summer of Code participants energy to help Wikidata which misses many must-be features. Some of them like support for projects other then Wikipedia is postponed to next years, but something tells me that it may be clone of existing functionality in most cases except one-to-multiple links in Wikisource :-)
Yes we have a few GSoC project ideas lined up. I will add the to the wiki in a bit. Features are not postponed to next year but to the second year of development which starts in a few days. Patience please. Things will happen as fast as they can :)
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata
Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Some of these probably aren't really that suitable:
After this filtering, we seem to be left with:
- An easy way to share wiki content on social media services
I don't think this is a good idea unless the political climate on wikipedia has changed (we want the gsocer to stay. Flame wars are probably not conducive to that)
- Write an extension to support XML Sitemaps without using command line
Meh, maybe. Rather low impact. Very few people fall into the use case, its debatable how much a sitemap would even help with seo. Its also not the easiest thing to do to make mw work on a schedule, especially if the task needs to be accomplished a little at a time.
- Extension:OEmbedProvider
Would be concerned that its not likely for the student to see their work used (deployed) after a single summer of work unless it was mentored by someone who would have the ability to deploy the extension themselves. That's obviously not a requirement and someone could do a lot of good work in the direction of making it useful, but something to keep in mind.
- Allow smoother and easier Wikimedia Commons pictures discovery
This is more - come up with cool ideas (which is needed) rather then an implementation project. Is that ok for a gsoc project?
-bawolff
On 03/20/2013 04:43 PM, Quim Gil wrote:
It's time to start defining what we want our Google Summer of Code to be all about. Let's look at the ideas we are proposing to potential students:
https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects
Edits fine tuning the descriptions of these projects are welcome in this wiki page.
(...)
After this filtering, we seem to be left with:
In the meantime I'm updating the list of project ideas we want to present to GSOC students at
https://www.mediawiki.org/wiki/Talk:Summer_of_Code_2013
Note that the project ideas are that: ideas. Suggestions for students. In our GSOC proposal we will need to find a balance between being generic and flexible about the types of projects we welcome, and also provide examples for newcomers to get the point.
A key factor of the selected ideas will be the availability of mentors in that area and the feasibility of its implementation and deployment.
But what really counts are the projects presented by the students, inspired from the ideas proposed. The inspiration might be a full copy of the idea by someone with the skills to implement it, or might be something different yet very interesting.
We'll see. This is one of the various iterations we will do in the following weeks.
On 03/20/2013 07:43 PM, Quim Gil wrote:
Most of these projects seem to be extension (and PHP?) centric. Can we have more diversity? Maybe gadgets and templates are too simple for a GSOC project?
A gadget can be quite elaborate. Examples (among many others) include Navigation_popups, Twinkle, and wikiEd. However, there are limitations to keep in mind. The most important is probably that gadgets do not yet have i18n support.
A well-written template or template/Lua module library could be at least one component of a project, in my opinion.
Matt Flaschen
Hi Quim,
comments are inline.
On Thu, Mar 21, 2013 at 12:43 AM, Quim Gil qgil@wikimedia.org wrote:
(...) After this filtering, we seem to be left with: (...) (If you think your project should also be considered here please speak up!)
Browser test automation[1]?
Most of these projects seem to be extension (and PHP?) centric. Can we have more diversity?
Browser test automation? Not an extension, not in PHP, but in Ruby[2].
(...) What about the mobile front?
We have some browser test automation for MobileFrontend[3].
Željko -- [1] https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Browser... [2] https://github.com/wikimedia/qa-browsertests [3] https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/tree/master...
On Fri, Mar 22, 2013 at 10:30 PM, Željko Filipin zfilipin@wikimedia.org wrote:
Most of these projects seem to be extension (and PHP?) centric. Can we have more diversity?
Browser test automation? Not an extension, not in PHP, but in Ruby[2].
OPs don't want [any more] ruby on the clusters, So I wouldn't suggest that.
We should be focusing on stuff that is achievable and that can easily be shown on benefit our users by actually getting it out there (we have a shocking record for this)
On Fri, Mar 22, 2013 at 6:55 AM, K. Peachey p858snake@gmail.com wrote:
On Fri, Mar 22, 2013 at 10:30 PM, Željko Filipin zfilipin@wikimedia.org wrote:
Most of these projects seem to be extension (and PHP?) centric. Can we have more diversity?
Browser test automation? Not an extension, not in PHP, but in Ruby[2].
OPs don't want [any more] ruby on the clusters, So I wouldn't suggest that.
We should be focusing on stuff that is achievable and that can easily be shown on benefit our users by actually getting it out there (we have a shocking record for this)
It's not on the cluster, we manage these in gerrit[0] and run these completely openly on a hosted service. https://wmf.ci.cloudbees.com/. This is after many long discussions with various ops folks over the past year.
These tests consistently find regression problems[1], and this week alone found regression issues with PageTriage and GuidedTour. It is achieved, it is demonstrably of benefit, it is definitely out there.
[0]https://gerrit.wikimedia.org/r/#/admin/projects/qa/browsertests [1] http://www.mediawiki.org/wiki/QA/Browser_testing/Examples
After going in details through all the proposals it turns out we only have 3 project ideas listed at
https://www.mediawiki.org/wiki/Summer_of_Code_2013#Project_ideas
The rest miss a mentor, a more solid justification of relevance and/or a demonstration of interest from the communities they want to help.
I have pinged the people that proposed 3 ideas, hoping that we will be able to improve them and list them at the GSOC page:
Lua templates http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#.5Bgener... We need at least one mentor confirmed, and at lest one proposal identified that would be welcome by the community and would keep a student busy during 12 weeks. I'd really really like to see this one happening.
Interwiki notifications framework for InstantCommons http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Build_an... Nice idea and Dereckson is volunteering as mentor but... do we have any idea about how this framework should be developed? Has this proposal been done before? If so, where it is and what the Commons community thinks about it?
Improve Extension:CSS http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Improve_... I like this one because it is proposed by a developer of this extension willing to mentor. More reasoning about the need and the implementation proposed would be welcome, and also impressions from other developers / maintainers. Your feedback is welcome at http://www.mediawiki.org/wiki/Talk:Mentorship_programs/Possible_projects#Imp...
Then we have another one that looks promising:
Bug 46440 - co-ment-like tool for inline comments https://bugzilla.wikimedia.org/show_bug.cgi?id=46440
On 03/22/2013 05:30 AM, Željko Filipin wrote:
Browser test automation[1]?
http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Browser_... 12 weeks of a student to get good coverage of MobileFrontend automated testing? Maybe, but... One thing is the amount of work. Another thing is that it feels like quite volatile / WIP work. I'm open to be convinced, though.
On 03/22/2013 05:36 AM, Guillaume Paumier wrote:> Hi,
This may sound naive, but why are "improvements of existing features" discarded?
Mmm ok, we can try. As you can see "Improving Extension:CSS" is now a candidate. Still we need to have the rest of pieces in place: mentor, justification, etc.
fwiw I pinged the former developers of the Extension:Bugzilla you are proposing at http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Improve_... - see https://twitter.com/quimgil/status/315526551762505728
On 03/22/2013 05:46 AM, Yuvi Panda wrote:
I've a good number of Mobile app ideas to contribute, but do not think I'll be able to mentor. Should I still put those in?
On 03/22/2013 04:40 PM, phoebe ayers wrote:
I have some ideas for existing features and extensions that could use a good summer's work, and I just added one of them to the page, despite not having any ability to personally mentor -- I assumed if there was interest it could get picked up by someone. I hope this is ok!
Yes please, at the Possible Projects page. It's good to leave your name as proposer and it's good to tell explicitly that you are not available for mentoring. We will decide whether to list them as GSOC 2013 project ideas or not.
But go for the most relevant one explaining it in more detail. You can mention briefly the rest. One good idea without a mentor today still stands a chance. Dumping many ideas with no mentor leave little chances to each.
Ok, let's move the discussion to
http://www.mediawiki.org/wiki/Talk:Mentorship_programs/Possible_projects
because this final sprint requires (hopefully!) many posts from many people.
Please go there if you want to help any of these candidates:
* Gadgets: needs at least one project idea and one mentor.
* Write useful Lua modules: needs at least one project idea and one mentor.
* Phase out the Vector extension; merge the good parts into core: needs maintainers' buy-in, a defined project scope and at least one mentor.
* Work on outstanding Parsoid bugs and/or add features: needs at least one project idea and one mentor.
* Improve Extension:CSS: needs more feedback from security & MediaWiki developers. (discussion thread)
* Add support for x3d 3D files to MediaWiki: needs more feedback from 3D savvy users and developers and at least one mentor.
* Improve the mediawiki-bugzilla extension to a deployable level: needs Bug Squad buy-in and at least one mentor.
* Work on RefToolbar: needs discussion (work on the extension or on a VisualEditor module?) and at least one mentor.
* co-ment-like tool for inline comments: needs at least one mentor.
* Build an interwiki notifications framework and implement it for InstantCommons: needs Commons feedback/buy-in and a second mentor.
* Browser Test Automation: needs at least one project idea.
* System documentation integrated in source code: needs more definition (a MediaWiki extension to integrate source code docs?), feedback / buy-in from MediaWiki developers and at least one mentor.
* Extension pages management: needs reasonable project scope, mediawiki.org community buy-in and at least one mentor.
Hi,
On Thu, Mar 21, 2013 at 12:43 AM, Quim Gil qgil@wikimedia.org wrote:
Many of the ideas listed there are too generic ("Write an extension"), improvements of existing features ("Improve Extension:CSS")
This may sound naive, but why are "improvements of existing features" discarded? My thinking was that, if the student didn't have to start from scratch, they would have more time to polish their work and make it fit with our strict standards, hence making it more likely for their work to be merged and deployed.
(Of course, the existing code needs to be good enough not to require a complete rewrite, but that could be decided on a case-by-case basis.)
I've a good number of Mobile app ideas to contribute, but do not think I'll be able to mentor. Should I still put those in? Does putting them in with your name attached convey 'hey, this guy might be able to mentor?' to people looking?
-- Yuvi Panda T http://yuvi.in/blog
On Fri, Mar 22, 2013 at 6:16 PM, Yuvi Panda yuvipanda@gmail.com wrote:
Does putting them in with your name attached convey 'hey, this guy might be able to mentor?' to people looking?
It usually does. At least interested students tend to assume as much.
-- sankarshan mukhopadhyay https://twitter.com/#!/sankarshan
On 2013-03-22 9:37 AM, "Guillaume Paumier" gpaumier@wikimedia.org wrote:
Hi,
On Thu, Mar 21, 2013 at 12:43 AM, Quim Gil qgil@wikimedia.org wrote:
Many of the ideas listed there are too generic ("Write an extension"), improvements of existing features ("Improve Extension:CSS")
This may sound naive, but why are "improvements of existing features" discarded? My thinking was that, if the student didn't have to start from scratch, they would have more time to polish their work and make it fit with our strict standards, hence making it more likely for their work to be merged and deployed.
(Of course, the existing code needs to be good enough not to require a complete rewrite, but that could be decided on a case-by-case basis.)
-- Guillaume Paumier
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I think improvement to exidting features are fine, but it should be existing features that are used by (or have a high potential of being) used by the wmf. If its a feature not used by wikimedia, it should have an extremely high impact on third parties to compensate.
-bawolff
On Fri, Mar 22, 2013 at 5:36 AM, Guillaume Paumier gpaumier@wikimedia.org wrote:
Hi,
On Thu, Mar 21, 2013 at 12:43 AM, Quim Gil qgil@wikimedia.org wrote:
Many of the ideas listed there are too generic ("Write an extension"), improvements of existing features ("Improve Extension:CSS")
This may sound naive, but why are "improvements of existing features" discarded? My thinking was that, if the student didn't have to start from scratch, they would have more time to polish their work and make it fit with our strict standards, hence making it more likely for their work to be merged and deployed.
I have some ideas for existing features and extensions that could use a good summer's work, and I just added one of them to the page, despite not having any ability to personally mentor -- I assumed if there was interest it could get picked up by someone. I hope this is ok!
-- phoebe
wikitech-l@lists.wikimedia.org