Topic on Talk:Outreach programs/Possible projects

Many of the ideas listed at Mentorship programs/Possible projects 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 are not suitable for GSOC.

After this filtering, we seem to be left with:

• Create a VisualEditor module
• Article evolution playback tool idea
• 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!

This post was posted by Qgil-WMF, but signed as Qgil.

Writing a VisualEditor plugin (e.g., "write a plugin to let users edit sheet music visually in the VisualEditor" or "…source code…" or "…poems…" or "…timelines…" or …) are an option that (a) didn't make your list, and (b) are written in JS, not PHP. :-)

JD that is somewhat similar to what I was wishing for. I do know that wikis are missing visual addition of music aspects. I am not sure where Extension:Score is currently situated but I know that it is sitting in bugzilla, and I would like to see something that will also work in and out of VisualEditor. So someone thinking about music in general, and then the aspects now and future. Long wished for, long resident in bugzilla.

Well, a Score editor would potentially be an immense project unless there's an existing JS editor out there that saves into Lilypond; so far all I've been able to find save into ABC…

VisualEditor plugins are now the first project idea officially proposed. Your edits to improve Summer_of_Code_2013#Project_ideas are welcome.

I would be happy to add a mention to Parsoid as long as we have also a specific proposal, a mention to the skills required and confirmation that there would be a mentor for this.

I will continue adding sections today. Stay tuned.

This post was posted by Qgil-WMF, but signed as Qgil.

I removed "An easy way to share wiki content on social media services." Let's avoid projects based on proprietary APIs, at least in the context of GSOC.

This post was posted by Qgil-WMF, but signed as Qgil.

It occurred to me that an inline comment tool could be a powerful extension to MediaWiki, particularly (but certainly not solely) for readers. See bugzilla:46440 and this EE thread.

This post was posted by Mattflaschen, but signed as Superm401.

Not to cookie-lick this (;-() but this is somewhat in the scope of the VisualEditor's rough plans for 2013/14; I'd love to work with someone on GSoC (or otherwise) on building something like this, though!

I love you.

Interesting. I originally suggested it for AFT, but clearly it would work well with VisualEditor (either using the VE API I've heard about, or built-in to the extension proper). I've CCed you on bugzilla:46440.

I have offered to act as a mentor should the project move forward. However, it looks like GSOC allows more than one official mentor (and of course we can have unofficial mentors too), so it would be great to have you or someone else from the VE team.

This post was posted by Mattflaschen, but signed as Superm401.

Happy to help out. :-)

This proposal has an own entry now: Mentorship_programs/Possible_projects#co-ment-like_tool_for_inline_comments. Looks good to me, and I'm willing to add it to the GSOC page as soon as we have a potential mentor or two...

This post was posted by Qgil-WMF, but signed as Qgil.

Two questions - what's wrong with being php- and/or extension-centric? MediaWiki is written in php, and its main strengths lie in its modularity - its extensions - so shouldn't a lot of these ideas involve one or both of those?

And if we have new ideas, where exactly should we add them? Since you've already picked through the main list, that doesn't seem an appropriate place to put them, but nor is a discussion. Is there a wiki page or section available specifically for GSoC project ideas anywhere?

Mentorship programs/Possible projects is still the pool of possible projects. Please add new ideas there.

This post was posted by Qgil-WMF, but signed as Qgil.

Nothing wrong with PHP and extensions, but there is more diversity of technologies under the Wikimedia umbrella and it is good to put some effort in promote it. This increases the quantity and diversity of students that we can reach effectively.

This post was posted by Qgil-WMF, but signed as Qgil.

Two bugzillas that regularly get prodded, and have plenty of history are around ...

• Extension:Cite which has a talk page full of issues that could do well to be updated, especially considering we now have Lua, so seeing that interaction work a whole lot better, AND the ability to have other tags work inside <ref> would be fantastic.
• bugzilla:18861 failing searches due to not expanding transcluded pages prior to indexing, such that any cross namespace transcluded pages are missed by our internal searches, so this means templates, and for the Wikisources, many of their proofread pages.

GSOC is mostly about developing new features. Ports and bugfixes stand little chance, regardless of how important they are.

This post was posted by Qgil-WMF, but signed as Qgil.

Ok, let me answer better. Fixing a piece of software might qualify as a GSOC project as long as there is a big task defined that would keep a student busy during 12 weeks. Pointing to a list of minor/normal issues is not an option, and this seems to the the case of Extension:Cite.

bugzilla:18861 is a High/Major bug assigned to Ram, who is a full time WMF developer. Not a good candidate for a GSOC project.

This post was posted by Qgil-WMF, but signed as Qgil.

frankly, as a general user/editor this seems all wrong -- how better to learn how to work on software than to actually work on existing software, with all its legacy flaws and issues? Cleaning up extension:cite, or any other highly used extension, will impact way, way more people than any of the stand-alone projects I see on the list. It might be harder to mentor and triage, but it seems like small stand-alone projects are often not so useful. Maybe this is part of the Google requirements (that you can't use the students as free labor) but I'd imagine most of these big extensions are pretty big intellectual challenges too, especially when considered as part of a system (around citations, or whatever).

I'm just saying that we can't tell students at Summer of Code 2013 to go through a talk page full of issues that could do well to be updated. Can you write down a paragraph describing what are the main problems of Extension:Cite and the impact it would have to fix them? Can you involve the Extension:Cite maintainers to make sure they agree and will be willing to take the work done by a GSOC student? Yet another question would be to make sure that there is someone willing to mentor this task.

Our main priority is to propose at the Summer of Code ideas that have the main pieces in place. Possible Projects page will be just one click away. This Talk page will be two clicks away. And they can come up with projects that are not listed anywhere.

This post was posted by Qgil-WMF, but signed as Qgil.

well, Extension:Cite wasn't my idea (it was posted by that IP) and I'm not sure what's wrong with it, so I can't answer your specific questions :) In general though maybe I'm just confused about what y'all are imagining as student projects. On the main page, under the guidance, "NO to variations of existing features" and "NO to projects done in a closet that won't survive without you" seem like they might be contradictory in practice, as many major needs do already have some kind of related features.

It isn't easy to write a simple generic statement covering all cases.  :)

If we make a specific decision that you consider wrong, please tell how we could do better. Right now I'm specially interested in projects we propose / discard for Summer_of_Code_2013 because that is the page that needs to be ready by Thursday. For all the rest we have extra weeks to discuss (including new projects that could be proposed).

This post was posted by Qgil-WMF, but signed as Qgil.

I've boldly changed the phrasing to prohibit *trivial* variations on existing functionality. I agree that substantial improvement in existing functionality is a reasonable project -- that's what Robin did last year, for instance.

I would love to see the watchlist system fixed so it can support categories.

TWISI, There should be two levels or options for watching a category:

1. being notified whenever a page either adds or removes the watched category
2. being notified for any change in a page belonging to the category.

currently, watching a category basically means you'll be notified for any change to the category page itself, which is not what a reasonable person would expect when they add the category to their watchlist (of course, after some experience most of us realize that watching a category is useless. there are some gadgets floating around that will add all the pages in a category to the user's watchlist, but this is not what i'm talking about above).

it is my understanding that such projects were stated and then abandoned (i might have misunderstood), and i think there are some extensions that try to address the category/watchlist junction, but as far as i saw, none of them did "The Right Thing" ™.

peace.

Thank you, these are interesting suggestions.

"Being notified whenever a page either adds or removes the watched category" is bug 7148.

"Being notified for any change in a page belonging to the category" is bug 1710.

Both old requests with clear support but stalled. Interesting! I will comment in those reports to make a reality check.

This post was posted by Qgil-WMF, but signed as Qgil.

you might also want to to peek in Extension:CategoryWatch.

it is my impression that this extension is stale, and in any event i do not think it should be an extension - this is core functionality.

i also don't think the extension functionality is complete.

peace.