New User Landing Page - Article Creation Workflow
Open, Needs TriagePublic

Description

Proposed in Community-Wishlist-Survey-2016. Received 63 votes, and ranked #14 out of 265 proposals. View full proposal with discussion and votes here.

Problem

en.Wiki receives around 850 or more new pages every 24 hours of which up to half are not suitable for publication. New users are unaware of what kind of articles are acceptable for Wikipedia or are unaware of the inclusion criteria before they start creating. New Page Reviewers are too few to contain the influx of inappropriate pages and to render basic assistance to new, good faith creators of articles.

Who would benefit

(cross-Wiki application, core software extension). Above all, the new users whose first attempts at editing are to create a new article. Other benefits are to those who maintain the processes for deleting inappropriate pages and/or offering basic help and advice to such users. Such a landing page would greatly reduce the need for answering the Why was my page deleted? questions, and processing AfD discussions. The serious backlogs at AfC and New Page Review would also be sigificantly reduced.

Proposed solution

Resume the development of Article Creation Flow, a WMF project that was begun as a solution to the WP:ACTRIAL project they denied despite an overwhelmingly large community consensus.. The purpose was provide succinct but comprehensive information before the users commenced creation, and to channel all new articles by first time new users through the w:WP:Article Wizard to be reviewed at WP:Articles for Creation or WP:Page Curation before being published in mainspace.

Time, expertise and skills required

  • Big project. Requires familiarity with javascript, CSS, and design

Suitable for

  • Hackathon, Volunteers

Proposer

@Kudpung

Related links

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 27 2017, 12:33 AM
srishakatux updated the task description. (Show Details)Feb 11 2017, 1:27 AM
This task was proposed in the Community-Wishlist-Survey-2016 and in its current state needs owner. Wikimedia is participating in Google Summer of Code 2017 and Outreachy Round 14. To the subscribers -- would this task or a portion of it be a good fit for either of these programs? If so, would you be willing to help mentor this project? Remember, each outreach project requires a minimum of one primary mentor, and co-mentor.
srishakatux updated the task description. (Show Details)Mar 10 2017, 11:45 PM
srishakatux updated the task description. (Show Details)Mar 10 2017, 11:47 PM
Kudpung added a comment.EditedMar 11 2017, 9:16 AM

Why is this still being shunted around from one dev to another as if its a 'w e l l... it c o u l d be done if someone or a 'program' were sufficiently interested/motivated, instead of it being a core Foundation priority? If the WMF had fully realised the negative impact not having this feature is having on all the work of volunteers' work of maintaining Wikipedia, they could have had it done and finished four years ago when it was first begun.
It's now taken 9 months to simply get thus far since I started making serious noises about in June last year. It could have been built and rolled out in that time alone.

This proposal didn't make the top 10, thus it's not a core Foundation priority, but I think being at #14 makes it appealing for developers to take on. Also, I don't think we should ever assume that something could have been done in a certain time period because many other things have been developed in that time frame, and there's only so many active developers to go around. If one thinks this should be prioritized higher, one should make that case.

"The Top 10'? You mean that 'letter to Santa' of convenience gadgets? Forgive me for reminding everyone but the strongest cases for prioritising this have been made for years - the project was even started by he WMF to stave off a community action the Foundation claimed (quite wrongly) conflicted with founding policy. What we are hearing now are typical politicians' arguments for not getting something done that is extremely urgent and necessary. More proof that those 'deciders' in the Foundation have little or no experience of administrative editing at the coal face and the wishlist scheme was about as realistic as the UK's Brexit poll or the latest US presidential election.

Kudpung, I don't see how comments like yours are constructive, much less advance this along. There are big ideas I'd like to see happen too, but I would not use a strategy like yours. Unless you chill, I have nothing else to say here.

MusikAnimal added a subscriber: MusikAnimal.EditedApr 5 2017, 12:26 AM

T147225 for the record, takes advantage of MediaWiki system messages which allowed us to do some of what the old New User Landing Page did. Specifically, this mockup would not need to be reimplemented. The other workflows would probably done in JavaScript, and installed on wikis a default-on gadget (maybe an extension?). That's my guess, I did not work on it the first go around. The one thing I can say is I don't think any strong MediaWiki or PHP experience would be required. I would also pay mind to the Wikimedia style guide, and perhaps even consider roping in a designer before moving forward with this.

srishakatux updated the task description. (Show Details)Apr 11 2017, 11:29 PM

Would anyone be interested in being a point of contact/ mentor/ available to answer questions for this task during the Wikimedia-Hackathon-2017? I would like to list your name here: T154988 cc @kaldari @MusikAnimal

MusikAnimal added a comment.EditedApr 27 2017, 6:19 AM

Would anyone be interested in being a point of contact/ mentor/ available to answer questions for this task during the Wikimedia-Hackathon-2017? I would like to list your name here: T154988 cc @kaldari @MusikAnimal

I don't mind being contacted about this, but I may not know all the answers :)

Frankly, unless I'm missing something, I think the remaining workflows could also all be done with on-wiki system messages and CSS, and probably without JavaScript. Going this route, one thing that we wouldn't be able to do is make the account creation form. We could simply have a link to Special:CreateAccount instead. Another thing I learned with T147225 is that experienced users do not want to see these pages, ever. Instead of "Skip this message in the future" which would require cookies or a database, we could do the same as we did with T147225 and utilize user group CSS and JS. So taking away the need for a gadget or extension, I'd estimate this solution should take no more than a week, if not a few days. The design will probably be the biggest challenge, and the community would be able to tweak it to their liking (but we should still try to abide by the style guide :)

MusikAnimal added a comment.EditedApr 27 2017, 6:28 AM

Well, the analytics part we obviously wouldn't be able to do. Perhaps that's important to some, not sure, but I can suggest that would make this otherwise goodfirstbug -ish task into a big project. It would be cool to see if the pages survive speedy deletion, as described. Perhaps we could use both system messages and a backend tracking service. This would allow us to get the numbers we want but permit the community to customize the interface. If the backend turns out to be too much work, you still have a largely improved workflow that the community has already expressed interest in.

(NOTE) This task was proposed in the Community-Wishlist-Survey-2016 and in its current state needs owner. Wikimedia is participating in Google Summer of Code 2017 and Outreachy Round 14. To the subscribers -- would this task or a portion of it be a good fit for either of these programs? If so, would you be willing to help mentor this project? Remember, each outreach project requires a minimum of one primary mentor, and co-mentor.

This critical issue project was actually proposed years ago and even begun by the WMF. It's objective was not to see more new articles surviving our various deletion process, but to avoid such articles (several hundred per day) being created at all and thus significantly reducing the workload at NPP/NPR to a realistic and managable influx of new pages.

The NPP backlog now stands at an astonishing 20,000 and growing exponentially (up by 20% in just the last 8 weeks) and there is now no way to get all new pages processed within the 90-day time limit for NO_INDEX. The volunteer community is currently discussing the implementation of local scripts which while not incurring complex design/programming of a welcome/help page, will simply force all new pages by all new users through the existing article wizard and into AfC - also already a completely overburdened process.

I still maintain that any development should be a Foundation funded priority, but with significant input from members of the volunteer community who have the longest and best empirical knowledge of what needs to be done. The analytics part at this stage, while naturally of interest, is therefore superfluous and would only further delay the start of some concrete development. We have tried many times to obtain similar stats just to provide additional support to what is already known, but the community has been unable either to formulate the strings for Quarry, or to locate any suitable logs for the purpose.

As always, as one of the major protagonists (and initiators) since 2012 for the urgent necessity of a proper Landing Page, and having been in the vanguard of NPP for even longer, I would be more than happy to participate while leaving the actual coding to the experts. There needs to be a clear distinction however, between the required solution and its psychological impact on new users, and the physical coding when that solution (with the help of workflow outlines and GUI design suggestions) has been decided. IMO these are different skill sets.

RHo added a subscriber: RHo.May 4 2017, 5:26 PM
cmadeo added a subscriber: cmadeo.May 12 2017, 8:01 PM

Hi! Let me know if you need any design help!

Removing the Possible-Tech-Projects tag as we are planning to kill it soon! This project does not seem to fit in the Outreach-Programs-Projects category in its current state, so I am not adding that tag right now!

Restricted Application added a project: Growth-Team. · View Herald TranscriptJul 12 2018, 5:46 AM
JTannerWMF moved this task from Inbox to To Triage on the Growth-Team board.Jul 18 2018, 6:32 PM
SBisson moved this task from To Triage to External on the Growth-Team board.Jul 20 2018, 6:35 PM