Talk:Outreach programs/Possible projects
Contents
| Thread title | Replies | Last modified |
|---|---|---|
| "Add your proposal" instruction details from template | 0 | 01:07, 26 February 2015 |
| Handling the projects lists via Phabricator | 0 | 07:01, 8 December 2014 |
| Microtask step | 1 | 17:19, 7 December 2014 |
| Updating this page for OPW - Round 7 | 0 | 23:03, 16 October 2013 |
| Reminder to scope small :-) | 2 | 21:32, 16 October 2013 |
| GSOC 2013 candidates missing one thing or two | 26 | 14:57, 20 July 2013 |
| Is it possible for teachers track students' performance from MediaWiki-based systems? | 0 | 18:41, 30 April 2013 |
| BiblioCommons API | 0 | 14:19, 14 April 2013 |
| Improve Extension:CSS | 6 | 14:31, 11 April 2013 |
| Pronunciation Recording Tool | 1 | 03:14, 9 April 2013 |
| List of project ideas | 25 | 06:01, 2 April 2013 |
| Phase out the Vector extension; merge the good parts into core | 1 | 21:41, 25 March 2013 |
| Polishing this list for GSOC'13 | 2 | 00:16, 24 March 2013 |
| *Don't* try a proposal regarding extension installation or updating | 0 | 13:52, 12 February 2013 |
The Outreach programs/Application template from last year has these questions. I'm pretty sure that a few of them but not most are covered in the Melange application process, so I'm leaving them here for reference in that I expect we will want student applicants to respond to the full set whether in Melange or in their phabricator tasks:
- Draft your project creating a new Phabricator task. Try to pick a short, memorable and catchy title which communicates your core idea on how to tackle the issue/project you chose.
- Describe the details and timeline of the work you plan to accomplish the project. Include a brief, clear work breakdown structure with milestones and deadlines. Make sure to label deliverables as optional or required. Deliverables should include investigation, coding, deploying, testing and documentation.
- Briefly describe your work style: how you plan to communicate progress, where you plan to publish your source code while you're working, how and where you plan to ask for help. Applicants that understand active participation in our development community will be favored.
- Please describe your education completed or in progress.
- How did you hear about this program?
- Will you have any other time commitments, such as school work, another job, planned vacation, etc., during the duration of the program?
- We advise all candidates eligible to Google Summer of Code and FOSS Outreach Program for Women to apply for both programs. Are you planning to apply to both programs and, if so, with what organization(s)?
- What drives you? What makes you want to make this the best wiki enhancement ever?
- Please describe your experience with any other FOSS projects as a user and as a contributor.
- Please describe any relevant projects that you have worked on previously and what knowledge you gained from working on them (include links.)
- What project(s) are you interested in (these can be in the same or different organizations)?
- Do you have any past experience working in open source projects (MediaWiki or otherwise)?
- Please add any other relevant information -- UI mockups, references to related projects, a link to your proof of concept code, whatever. There are no specific requirements, but we love to see people who love what they're doing. Show us you're excited about this project and have an interest in the background and are considering how best to make your idea work.
The list of projects ideas in this page could be better handled as two Phabricator projects:
- Possible-Tech-Projects
- Possible-Tech-Projects-(Raw)
We would keep the static intro here, but the actual lists of projects would be based on Phabricator tasks to avoid duplication of content and deal better with tags.
See the corresponding Phabricator task: Convert mw:Mentorship_programs/Possible_projects in two Phabricator projects
Someone wonders if the step of completing a microtask should be reiterated in the instructions/workflow for submitting a proposal. It's currently mentioned in Mentorship programs/Lessons learned which is linked as mandatory reading twice, but it's not included in "Add your proposal" section and is not marked as required in the template («If you have already written a feature or bugfix in a Wikimedia technology such as MediaWiki, link to it here; we will give strong preference to candidates who have done so.»).
I added it to Google_Summer_of_Code_2014#Candidates but then I forgot to reply here. Thank you || sorry. :)
We need to clean this page, making it ready for Outreach Program for Women - Round 7. If you have projects listed, or you simply want to help, please edit away. Every project at the Featured section must be ready to start in January 2014 with two mentors. The rest must go to Raw, or be removed.
I suggest we scope the featured code-related ideas at about 6 weeks of coding work to ensure we dedicate enough time (out of the 3-month period) to bugfixing and code review. Past proposals often allotted either no time or about 2 weeks for merging with trunk, pre-deploy code review, and integration. That's not enough. If skilled developer thinks that a project might take about 2 weeks for a skilled developer to code, then that's a good sign, in my opinion. Students run into lots of problems, and your 2-week project is someone else's whole summer or winter.
Just a reminder. :-)
Yes, indeed. I will add this to the lessons learned, which is also the checklist for future programs.
See "The core tasks shouldn't take more than 50% of the available time." at Mentorship programs/Lessons learned. Thank you again.
I promise this is the last thread I open with a list of GSOC 2013 candidates. I will keep it updated, notifying about the projects that make it to Summer_of_Code_2013#Project_ideas and the ones that get discarded.
- Improve the mediawiki-bugzilla extension to a deployable level: needs Bug Squad buy-in and at least one mentor. Discussing with Mozilla.
- Multilingual, usable and effective captchas: project scope needs clarification. Too much / too vague for a GSOC project?
- Mentorship_programs/Possible_projects#MediaWiki LocalisationUpdate for all: does it have MediaWiki core maintainers buy-in?
- Mentorship_programs/Possible_projects#Multilingual SemanticMediaWiki: does it have SMW maintainers buy-in?
Proposed:
- Improve Extension:CSS.
- Wikidata Entity Suggester.
- Prototyping inline comments.
- Add support for x3d 3D files to MediaWiki as part of New media types supported in Commons
- Tools for migration to structured page translation.
- Create plugins for jQuery.IME for Firefox and Chrome.
Discarded:
Extension pages management: nice idea but with unknown origin/promoter, requires significant planning and buy-in from mediawiki.org.System documentation integrated in source code: too complex for GSOC - see bug 46526.Work on outstanding Parsoid bugs and/or add features: the Parsoid team has big release in July and they are very busy. Not the best time for a student to land.Work on RefToolbar: we want to promote work on VisualEditor instead. The first release this Summer has basic cite support, and more can be added later on.Phase out the Vector extension; merge the good parts into core: not considered a good GSOC task in the current status of the project. (discuss)Browser Test Automation: considered not a good fit for GSOC.Improve accessibility of MediaWiki and MediaWiki extensions: not suggested anymore.Gadgets: no project.Write useful Lua modules: no project.Build an interwiki notifications framework and implement it for InstantCommons: nobody answered.
For the x3d one. Well it wouldn't be my first choice for a project to mentor, however if I was not mentoring something else and there was a student really interested in it I could probably mentor that. On a similar note make a kml validator/media handler would also possibly make a good media-handler-extension gsoc project (and maybe a little better scoped than the x3d one)
Wouldn't KML support be bug 26059? High priority, assigned to nobody, 30 comments 16 followers and stalled... Do we really want a student to jump there? If you want to test the waters in the report please do. I'd rather put my time pushing current project candidates to become actual GSOC ideas. An equivalent to "feature freeze", I guess.
Yeah that is the bug. I would just reccomend it be considered before x3d since from a technical prespective its almost the same project, but about half the work (and also probably has more people who care about it)
X3D support for mediawiki can be simplified by using the open source x3dom.js (http://www.x3dom.org/) - after that it's mostly about whitelisting the X3D tag set.
What about having a catch-all entry at the GSOC page for unsupported file types in Commons/MediaWiki? We could explicitly point to KML, x3d (anything else highlighted?) and link to the full list at Commons.
Discarded: Extension pages management: nice idea but with unknown origin/promoter, requires significant planning and buy-in from mediawiki.org.
I'm available to mentor the E:CSS, E:UploadWizard, the XML sitemaps extension, automatic category redirects, and/or E:OEmbed*. Which one I do I'll leave up to somebody who has a better idea of which projects WMF would prefer. Depending on the time commitment involved, I may be able to mentor more than one project.
If you could mentor Category redirects then bawolff would be available for another one. This is all relative since we might end up with other combinations as soon as interesting project proposals from students show up, but it would be a good combination to start with.
Sounds good to me.
Discarded: Work on outstanding Parsoid bugs and/or add features: the Parsoid team has big release in July and they are very busy. Not the best time for a student to land.
Discarded: Work on RefToolbar: we want to promote work on VisualEditor instead. The first release this Summer has basic cite support, and more can be added later on.
- Browser Test Automation: needs at least one project idea.
I am not sure what would be a good project idea. For now we have this: "The goal would be to create decent test coverage for a feature or an extension. ... Good example would be Extension:MobileFrontend extension." Is that good enough?
As said in wikitech-l: 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.
We need to solve this today. Let's chat / talk.
Discarded: Browser Test Automation: considered not a good fit for GSOC.
Proposed:
- Tools for migration to structured page translation.
- Create plugins for jQuery.IME for Firefox and Chrome.
Discarded:
Improve accessibility of MediaWiki and MediaWiki extensions: not suggested anymore.Gadgets: no project.Write useful Lua modules: no project.Build an interwiki notifications framework and implement it for InstantCommons: nobody answered.
Suggestion, "Implement SASS or LESS support in ResourceLoader". It includes implementing bugzilla:46546 (languages like SASS or LESS in debug mode), and then one or both of bugzilla:46545 (SASS) and bugzilla:40964 (LESS).
Good! Assuming that the maintainers are ok with this. Please write a more explanatory description under Raw projects. Thank you!
I've added details at Mentorship_programs/Possible_projects#SASS.2FLESS. Let me know if more information would be helpful (some additional info is at the linked bugs). I also linked there from the SASS and LESS bugs.
I could also probably mentor this project as well if needed.
Hello, I hope I am not writing in the wrong place. I am a student(4h year in Department of Informatics, University of Athens) interested in Gsoc and would like to apply for a project in wikimedia. On this page: http://www.mediawiki.org/wiki/Summer_of_Code_2013 (Incremental data dumps -> https://bugzilla.wikimedia.org/show_bug.cgi?id=28956 and especially this post: http://www.mediawiki.org/wiki/User:ArielGlenn/Dumps_new_format_%28deltas,_changesets%29 ) I have found an interesting subject that I have some experience with. Is this still open, because on this page I don't see it anywhere? My experience on this issue come from my involvement recently in the Sigmod 2013 Programming Contest, where we faced many similar issues. The competition was in C++ but the theoretical background is similar and XML-Python will definitely not be the problem I imagine. If this project is not available any more, it would be really helpful to point me towards something else available and similar. I have strong skills in C,C++,Python,Java,Web Languages(JS,CSS,PHP,HTML) and the ability and time to learn anything else needed.
Hello Sibetheros! The best place to ask is indeed bug 28956. You can also contact Ariel directly (who coincidentally or not happens to be a fluent Greek speaker) via IRC or email.
Is it possible for teachers track students' performance from MediaWiki-based systems?
Just dropping this here in case the Wikibooks people have any particular thoughts.
Improve Extension:CSS
Considering the proposal to Improve Extension:CSS for Summer_of_Code_2013#Project_ideas... Could we have a reasoning of what needs would this solve in real projects out there? The idea sounds interesting and it is good to see a mentor backing the proposal. The proposal would gain strength if it would be clearer what are the specific problems or limitation MediaWiki sites are facing that would be solved with this project. I get the idea that now they can't use full CSS to style a single page. The question is though who wants to do this and why.
I can see somehow that better per-page CSS capabilities might help building visually attractive wiki pages and follows the line of giving more power to editors as we are doing with templates and gadgets. Still, more feedback from other developers and maintaners would be welcome.
Also more information about the mentor and his involvement in the MediaWiki / Wikimedia community would be welcome. There is not much said in the user profile(s) and I lack more background.
Thank you!
Thanks for the feedback Qgil.
My primary interest in Extension:CSS is for wiki installations with trusted users. Often these are private/internal wikis or CMS type configurations. In these cases, I have found it beneficial to give editors more control over formatting. Often times there are one-off tables or portal pages where editors want to customize the presentation.
One of my goals for WikiFYD is to provide a variety of layout/formatting examples for portal pages, tables and other complex information. The CSS for each example would be included so anyone (with the extension) can easily use them.
Does that help?
I have also updated my user page with some relevant information.
Could those "trusted users" be defined group permissions like e.g. the editors group here?
It would be difficult, wouldn't it? How do you (cleanly) prevent non-privileged users from adding/editing CSS rules in an otherwise editable article?
Ah, yes. Just for the sake of discussion: :) what about having an edit submission check or a bot looking at new edits to detect CSS code. Whenever a page gets new or edited CSS code then Extension:FlaggedRevs would set that page for review by a CSScops user group. You could decide whether to show the last version of the page or not, and to which users. I'm no security expert but maybe you could activate FlaggedRevs only with specific CSS code regex instead of just anything.
Anyway, I'm digressing. I just want to make sure we don't support a project for GSOC that later on someone says that brings security holes to a MediaWiki installation.
I need a mentor to guide me on the project
Rough Proposal
I might be able to do this if one of the current projects I've volunteered to mentor doesn't happen; I'd prefer not to do all three.
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!
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.
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.
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.
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.
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!
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 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...
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.
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.
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.
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.
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.
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:
- being notified whenever a page either adds or removes the watched category
- 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.
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.
According to the maintainers this is not a good idea. However, there might be a chance for a project consisting in fixing open Vector issues.
We need to find a scope. The tracking 44881 is just too broad. Would it make sense to have e.g. a selection of UI improvements in the nav bars? Fixes or features that can be agreed with the maintainers and that they will take when meeting the quality criteria. NOT features that would require wide discussions e.g. with the Wikipedia community.
If something along these lines is possible and there is at least one mentor, we can take it for GSOC 2013.
After discussing with Trevor Pascal, we didn't find a good scope for GSOC project. The tasks that remain are quite dull, far apart from a meaningful contribution to Vector skin UI improvements.
GSOC projects aiming to improve skinning features in MediaWiki are still welcome. For instance, how to have one skin with different color patterns that could be applied via preferences.
We need to work in our application for Google Summer of Code 2013. A basic piece is the list of projects we are proposing. This page is the main reference. Make sure the projects you want to see becoming a reality are a) listed and b) well featured. Having explicit backing of the related teams / stakeholders is also key.
I(really) don't know what the goals for GSoC in this year, but if you can... I would like to see students working with bugs related to item 6 of section The Big Picture[1]
For example (if I'm right) bug 5856 [2] or maybe the bugs 10384 [3] and/or 38271 [4]
Thank you for your feedback!
It would be great to have a Latex centric proposal + mentor. There seems to be potential for many little improvements but I don't know the problem enough to identify one potential GSOC project.
About svg-edit, I have commented at the bug report asking for proposal + mentor.
One popular request is some kind of update panel or extensions installation manager. But we shouldn't suggest that new developers try this; that would require improved configuration management first, and the scope is not right for a mentorship project proposal. This is just going to have to wait for several months until we have better configuration management and it's way too big.
