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.

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.

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

In T156442#3173873, @srishakatux wrote:

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 :)

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 good first task -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.

In T156442#3060088, @srishakatux wrote:

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.

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!

I was led to this task while searching for a similar solution in Wikiquote. I'm an admin at the Albanian Wikiquote and for the moment we have only 5 specific formats an article can be written according to its subjects. For example, an article about a movie requires different sections than, say, an article about a living person. We would benefit much if a special page about article creation, similar to the one described here, was made possible. We could present the user with 6 different forms with preloaded specific sections (one for the articles not belonging to the other 5 categories) and greatly facilitate the creation process. The preloading process would greatly help in the standardization process at the needed levels when a process like that is possible. For example, the Albanian Wikiquote would require a much detailed preloaded page because all the articles have the same sections. The English Wikipedia isn't that strict on that sense but it still has some specific sections that are present in many categories of articles depending on the subject.

Therefore I'd be greatly interested in seeing this feature at work not only for EnWiki but for all MediaWiki projects. The community can then modify it according to their needs. It would really help if it came with the possibility of preloading specific code at pages, a bit similar to the file upload wizard.

PS: An article creation wizard isn't hard to create by one's project's community. The problem is finding a way of "forcing" all the creation process (or maybe some of it in specific occasions, for example with new users) in the aforementioned wizard. Much like the file upload process works. Making it a core MediaWiki feature accompanied by the preloading feature would make it easier to implement and modify it according to communities' needs.