Page MenuHomePhabricator

Convert mw:Mentorship_programs/Possible_projects in #Possible-Tech-Projects
Closed, ResolvedPublic


The list of projects ideas at could be better handled as a Phabricator project: Possible-Tech-Projects

We would keep the static intro there, but the actual lists of projects would be based on Phabricator tasks to avoid duplication of content and deal better with tags.

Event Timeline

Qgil claimed this task.
Qgil raised the priority of this task from to Low.
Qgil updated the task description. (Show Details)
Qgil changed Security from none to None.
Qgil subscribed.

I think it would make sense to have a single project, with a workboard of different columns, one of which is "to expand project request" or something (which is to what "raw" corresponds).

Other columns could be "available", "needs discussion", "underway GSoC15" etc.

That would work as well. Good idea.

Qgil removed Qgil as the assignee of this task.Dec 16 2014, 8:12 AM

Removing this task from my backlog for now. If someone wants to work on this, great. Otherwise I will do it when it's the time to prepare the next GSoC / GSoC round.

Ah wait, now I remember. I had thought about converting this in a GCi task. Ooops, sorry for the noise.

Qgil raised the priority of this task from Low to Medium.Dec 19 2014, 8:21 AM
Qgil lowered the priority of this task from Medium to Low.Jan 12 2015, 7:27 AM

Meh, too late. I'm leaving this task for the next GSoC/OPW round preparations.

Qgil raised the priority of this task from Low to Medium.Feb 9 2015, 7:26 PM
Qgil renamed this task from Convert mw:Mentorship_programs/Possible_projects in two Phabricator projects to Convert mw:Mentorship_programs/Possible_projects in #Possible-Tech-Projects.Feb 9 2015, 10:44 PM
Qgil updated the task description. (Show Details)
jayvdb subscribed.

I've coverted two of the Pywikibot tasks: T74065 (recycled) & T89067 (new). Will wait for feedback, etc before doing the remainder.

Restricted Application added a subscriber: Unknown Object (MLST). · View Herald TranscriptFeb 10 2015, 1:59 AM

@jayvdb, thank you very much! You mean the remainder pywikibot projects, or the remainder Possible Projects in general? I do welcome help, just in case you were wondering. :)

I have documented the requirements for Featured Possible-Tech-Projects here. In every GSoC / OPW round we have seen that projects with a low score in that list of requirements had a lot more difficulties during the program, and I believe we need to be more strict for everybody's benefit. I will add this to as soon as we agree on these requirements.

I mean remainder of pywikibot, but thx for asking :P

Those criteria for 'featured' mostly make sense to me. Community consensus is a bit vague; as software features only needs a dev community consensus as opposed to project community consensus, provided the feature can be disabled. And a dev community consensus typically depends on the implementation more than the concept, precisely because it can be disabled so the main concern is perf and maint costs vs utility and both sides of that equation depend on how well it is built.

About community consensus, I recall several projects that made total sense to the mentors proposing them, but found objections from other veterans in the house, i.e. T64960 & T48704, and having candidates working on project proposals while community members were discussing was not fun at all.

Was T48704 held up by deployment to MediaWiki - i.e. project community consensus / ops approval ?
T64960 also looks like that might have been the problem.
Perhaps an alternate approach is questions "Which community consensus is needed?" followed by "Which community consensus has been obtained?"
For pywikibot, we would need a project consensus for a feature which is targeted at a project (e.g. implementing Welcome bot for Wikisource (T87232)), but not for adding OAuth support. But we might want a ops/security review before merging OAuth support for pywikibot.

Niharika has volunteered to take this task. Thank you very much! If you have questions, just ask. I'm watching both the Possible-Tech-Projects project and the Possible_Projects wiki page, and I might help editing here and there.

@jayvdb, mmm ok, I have removed the community consensus part as a required field. Each case is different, and in most cases the consensus is clear and driven by the own mentors pushing the project.

Maybe we could encourage people to endorse or show their disagreement using tokens (in addition to comments, of course). One day we will use tokens for code review (according to current plans), and this is a similar idea.

@NiharikaKohli you are creating many duplicates that I'm merging after you. The Possible_Projects wiki page already offers links to Phabricator tasks in many project ideas. You don't need to create new tasks for those.

@NiharikaKohli I have also closed some tasks about projects from the ongoing OPW Round 9. Not you fault because the page still needed to be updated.

@NiharikaKohli has moved all the content that didn't have an own task (except the "Very raw projects", which I don't think it's worth moving at this point) and now everything is visible at Thank you! That was fast.

What is left to complete this task:

  • Tasks that mentioned mentors or authors should have those users CCed when possible.
  • All tasks should have at least one project associated in addition to Possible-Tech_projects.
  • All these projects need to be removed from (I will continue editing that page to integrate it with the new Phabrcator project.

Niharika mostly completed the final steps, and I did the last mile. Thank you Niharika! Resolving. is now a lot shorter. I will still improve it, as part of T921.

It is more efficient to have the project idea description in one place instead of two, and it is more efficient to have them here among the rest of tasks than in a separate page that most of the time is not checked by almost anyone. See T76341.

It's not more efficient for us, because now we have three false tracking bugs, or three Translate-related Phabricator items which don't belong to the Translate component. This effectively discourages proposing projects which have clear deliverables in the form of existing bugs. Are our former featured projects no longer desired? Should we imagine projects which are more disconnected from "standard" bugs and feature requests?

Also, it's now impossible to group projects by theme, to link the descriptions with existing software projects on, as well as to skim all the proposals at once. Moreover, it's impossible to *edit* the project descriptions quickly, as we used to do very often on the wiki.

Finally, why are software projects by interns removed from the main namespace, where all the software projects by WMF and others reside? Why this discrimination?

Another problem: the "priority" field makes no sense.

I also don't appreciate the degradation of my descriptions, from which links and markup were removed.

In general, the current system is more efficient. A project idea is in fact an open task, and here project ideas sit in their actual context of associated projects, related tasks, subscribers, and also priorities (the priorities set by their mentors / maintainers, just like in any other requested feature or open task). We might have lost some advantages, we might have been more accurate when moving a dozen tasks or more... but the overall benefits of handling and maintaining a single list of possible tech projects here are quite clear.

We have just moved this process to Phabricator this week. There is room for improvement, agreed. Ideas welcome.

Finally, why are software projects by interns removed from the main namespace, where all the software projects by WMF and others reside? Why this discrimination?

I don't understand this part. Can you explain, please?