Following the closure of a month-long RFC-discussion on the English Wikipedia, there appears to be a very strong consensus in favour of permanently implementing the ACTRIAL restrictions by May 3,2018.
So, please work towards implementing the same on a permanent basis.
I think there would be support for moving ahead faster, but the date of 3 May 2018 shall be the latest.
@TonyBallioni Please do not change the priority without firstly consulting. Priority field is for those who work on particular tasks and it should not indicate the importantness for the requestor directly. This is is low priority because it requires discussions between sysadmins, it isn't "that simple" ;). Maybe normal, but certainly not "High" (High generally means "something is going to be broken if this won't be processed very soon").
@Urbanecm: given that this is a request from a 200 person plus RfC to restore one of the most significant changes to the flagship project, within a week and a half, and I’ve been told by a WMF staffer that 3 May is an acceptable date, yes, it is that simple.
Well, currently the extension that took care about ACTRIAL restrictions is undeployed (according to T186570) and deploying extensions really isn't simple from my point of view (for me, simple == eligible for SWAT; according to https://wikitech.wikimedia.org/wiki/SWAT_deploys, No new features/extensions are allowed). But of course, it is (technically) possible, but I'm not sure if before 3 May.
@Aklapper: I emailed Danny Horn about it in the final week of the RfC to make sure he was aware that the close was likely to be positive. He responded saying if it passed the 3 May date would be fine. Toby Negrin, Ryan Kaldari, and Marshall Miller from the foundation were copied on his response.
Let's leave it to the maintainers/developers who'd work on this to define the priority of this task.
I don't see any ComTech member on this thread yet, (despite them being constantly kept in loop by Tony and a few others as to the progress of the RFC) and the responses from Martin and Akllaper are non-satisfying to say the least.
Thus, can anybody give a perfect time-frame for the deployment of this request or is it the typical--When any volunteer gets time........?!
Also, I have little clue as to why proposals which have gained such a strong consensus in one of the most major and prominent flagship projects, of all existing ones, shan't be a priority for the developers?! Obviously nobody is seeking a UBN but................
@Aklapper @Urbanecm this is high priority. There is to be no more debate. The technical intervention to implement the trial was easy enough. Please be good enough proceed with this very quickly, Anything else would be pure procrastination and would damage the very fragile good relations that we have carefully groomed with the WMF recently, who spent a lot of money on the research, stats, and final analysis. Other urgent on-going community developments supported by the WMF depend on this being rolled out now.
Thanks.
@Kudpung; Unfortunately, when one is up against a 200-editor plus RfC, procrastination probably *is* the only agency left...
the date of 3 May 2018 shall be the latest.
I think it shall take a week (next Thursday) at maximum....And, I would highly appreciate a fast-tracking.
given that this is a request from a 200 person plus RfC to restore one of the most significant changes to the flagship project, within a week and a half
There is to be no more debate
I'm just going to say this...again. Whenever I read things like this in tickets, my mind goes: "i'll put this at the bottom of my to-do pile, thank you very much" and i'm pretty sure I'm not alone in that. And since all these kinds of requests are basically very much dependent on the energy of WMF employees outside of their scheduled activities, they are therefore not helping you to achieve your goals.
Bollocks. This is core developer activity, responding to the requests and requirements of the WMF and the Wikimedia communities that the WMF exists to serve.
I've emailed @Tnegrin, @DannyH, and @kaldari asking them to comment on this.
I do think it was a bit tone deaf for a volunteer on another project who likely was unaware of the background here and how the original veto of this by the WMF was one of the largest sticking points in the en.wiki-WMF relationship for years to triage this as "low priority", but that is water under the bridge at this point. The best thing to do for now is to wait to see what the Foundation says rather than argue over this ticket.
I think you are misinterpreting my hate towards the English Wikipedia as a love for WMF.
Anyways, this thread laid entirely idle for about a week, before Tony stepped up the tempo by changing the priority, which actually drew some attention to the ticket.
If you want activity, I suggest to find another forum where you can talk to each other, instead of continuing to bait developers in this ticket.
And, since such comments apparently put you off, do we beg you to execute these changes?
Sorry, as a volunteer I have every freedom to work on things as I please, just as much as you have no responsibility to turn 5.6 million articles into featured articles. And as stated, it is at the very back of my queue.
I will also point out https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette for those wishing to continue engaging in baiting.
I cannot talk for each team's specific plans and time management, but let me try to elaborate on software development in general and provide some background: Regarding time frame expectations to work on requests brought up, all teams have plans (or as TheDJ called it above, "scheduled activities") Results can be seen as high-level goals per quarter and as tasks tracked in sprints.
Some tasks might totally be "high priority" for some individuals or for a specific community. On the other hand, our movement has ~900 wikis and each of these ~900 communities might also have their own [high] priorities. Given that (wo)manpower is limited, priority assessments might differ.
@WingedBladesofGodric: Regarding T192455#4157095, please either stick to the Code of Conduct and the Phabricator etiquette or refrain from posting. Thank you for your understanding and for keeping a civil tone.
Having had a quick look per this wikitech guide on adding an extension, it notes:
do this by adding the extension to the extensions array in make-wmf-branch/config.json in mediawiki/tools/release.git, and then waiting for two new branches to be created (ie. you have to do this two weeks before deployment!)
ArticleCreationWorkflow was recently removed from make-wmf-branch/config.json in rMREL40677bb037f56e705e5cffae8d7de79a786f1f1e.
Will this two week wait be required? Or will it be possible to follow:
When in a hurry, you can also just create the submodule by hand, as described in /Adding_a_new_submodule (you should of course still update config.json)
If this two week wait is not required (either by being able to create the submodule by hand, or another reason), would someone kindly be able to step us non-technical folk through what changes will need to be made to facilitate this change? I appreciate this is not normally done, but perhaps it will help calm the tone and give everyone perspective on the task at hand?
My understanding is, once the extension code is present on the servers, adding it to the extension-list and wmf-config files (a la reversing https://gerrit.wikimedia.org/r/#/c/419077 and related) would practically enable the extension.
(My thanks to @Aklapper for their guidance in keeping this task on-topic and civil)
Hi all — I'm Trevor, a WMF Product Manager on the Community Tech team (the team that helped facilitate ACTRIAL and runs the Community Wishlist project, amongst other responsibilities.) @DannyH and @kaldari are the two WMF staffers driving this project (to avoid too many cooks in the kitchen) so I am only in a position to provide context.
WMCON Berlin travel and time zones are affecting WMF staff response times, but I can say this is definitely is on our list of important projects. We are sorting out the details of closely related topics as well — the event coordinator proposal and AfC improvements, both of which are affected by changing the requirements for users desiring to create new articles.
We can't offer a specific deadline right now, but we do want to permatize this in a timely manner. We have meeting today in a few hours, I'll provide an update after.
Thank you!
We're interrupting our current Community-Tech Sprint to work on this next week. There will be no functionality changes, but we will redeploy the extension and enable it only for English Wikipedia. We're attempting to do this the week of April 30.
Change 429017 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[operations/mediawiki-config@master] Redeploy ArticleCreationWorkflow, part 1
Change 429100 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[operations/mediawiki-config@master] Redeploy ArticleCreationWorkflow, part 2
Change 429102 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[mediawiki/tools/release@master] Resurrect ArticleCreationWorkflow
Change 429111 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[mediawiki/core@wmf/1.32.0-wmf.1] Add a module for ArticleCreationWorkflow
Thanks @kaldari. The en.Wiki is the Foundation's flagship project. Important things that need doing to it should take precedence whether they are 'scheduled' tasks or not.; this particular task has been forseen for a long time.
The research the WMF provided for ACTRIAL due to its urgency, and the work they doing for AfC as a follow up are enormously appreciated - especially by me - but even what happens for AfC depends entirely on the roll out of ACREQ.
Let's just get this thing on the road, please, and many thanks in advance for those who are doing it. It shouldn't be complicated.
And as an aside, I don't believe it's appropriate for volunteer devs from other projects who are not even in the loop to be involved in setting such priorities.
[still aside] If you're unclear on how priorities are set in Phabricator, that should probably be discussed elsewhere. The volunteer developer you're referring to is one of the main people who processes site requests like these, and quite frankly, does a great job at it.
Yep. What MaxSem is doing in https://gerrit.wikimedia.org/r/429111 is basically the "hurry" option.
@Kudpung: Wrong. Feel free to discuss meta-level discussions in the appropriate places for meta-level discussions. mw:Phabricator_etiquette explains this.
Hi all,
Everybody can really chill out about this ticket. It is, was and will be the intention of the Community Tech team to make the non-autoconfirmed change permanent next week, as we said that we would. Everything else that's going on here is a series of misunderstandings. It would be great if we could just go and make that happen, without extra stress on anybody's part.
Change 429102 merged by Chad:
[mediawiki/tools/release@master] Resurrect ArticleCreationWorkflow
Change 429111 merged by jenkins-bot:
[mediawiki/core@wmf/1.32.0-wmf.1] Add a module for ArticleCreationWorkflow
Change 429017 merged by jenkins-bot:
[operations/mediawiki-config@master] Redeploy ArticleCreationWorkflow, part 1
Mentioned in SAL (#wikimedia-operations) [2018-04-26T21:14:03Z] <maxsem@tin> Started scap: Deploy ACW to test wikis, https://gerrit.wikimedia.org/r/429017 / T192455
Mentioned in SAL (#wikimedia-operations) [2018-04-26T22:11:10Z] <maxsem@tin> Finished scap: Deploy ACW to test wikis, https://gerrit.wikimedia.org/r/429017 / T192455 (duration: 57m 06s)
Change 429100 merged by jenkins-bot:
[operations/mediawiki-config@master] Redeploy ArticleCreationWorkflow, part 2
@Aklapper Wrong again. We are all grateful to Danny for moving this forward as a priority. Following the advice in the page you pointed me to, I have emailed you. Good Faith is a Wikimedia policy, please take it as such.
We got a report about several comments in this ticket.
We want to ensure a welcoming atmosphere in our technical spaces. While we support a free discourse, we condemn personal attacks. This is a general request for everyone involved in this discussion to keep your tone civil and polite before we have to use harsher means to make this discussion constructive.