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.

Possible-Tech-Projects created.

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

@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 https://www.mediawiki.org/wiki/Outreach_programs/Possible_projects 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.

@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.

@Qgil Oops, sorry.

@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 https://phabricator.wikimedia.org/project/board/1042/. 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 https://www.mediawiki.org/wiki/Outreach_programs/Possible_projects (I will continue editing that page to integrate it with the new Phabrcator project.

In T89102#1031093, @Qgil wrote:

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 mediawiki.org, 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 mediawiki.org 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.

In T76341#1031150, @Nemo_bis wrote:

Finally, why are software projects by interns removed from the mediawiki.org 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?