Although the specific projects have not been defined yet, I think their ultimate goals are clear: improve the acquisition and retention of new editors. Regardless of the type of project and approach, it will be very useful to have metrics and instrumentation to measure the impact on such goals.
This will allow to establish a baseline first, and then evaluate the impact of any initiative in this area. I created a ticket to capture the proposal in case anyone is interested.
Hi @Pginer-WMF, I agree. Personally, I see metrics and instrumentation as essential. Thanks for being pro-active in suggesting this! To be honest (because I'm a completely newby in most things) I'm not sure what happens next. Would you very briefly explain what a (wikimedia) ticket is? In general/ICT terms I know what it means. Just not what it means in the Mediawiki context. A link to somewhere where this is explained would be great!
I read a lot about the consensus approach to moving forward with anything. Would you (for me as a newby) just briefly summarize how tickets gather support (or not)?
Many thanks for your initiative and for your patience with a newby!
Mikemorrell49 (talk) 16:33, 23 November 2017 (UTC)
An item on Phabricator is a task or ticket. Phabricator is a site mainly for things that directly or indirectly require programming or configuration changes. It's mostly used by Foundation staff and volunteer techies, but it's open for anyone to submit new items or to discuss how tech issues will be resolved. Few editors/administrators venture onto the Phabricator techie-zone. (Note: Admin are editors, promoted to admin by other editors. A very small number of admin also happen to be staff.)
Your question about consensus is complicated, chuckle.
The specific ticket here, T181249, is a simple case of Foundation staff wanting metrics and instrumentation. Tech staff will handle that just like any conventional employer-employee authority model.
There are also a huge number of small uncontroversial fixes and improvements made by the Foundation every month, without dealing with consensus.
If anyone posts a valid bug report, it will generally just get fixed. No need to discuss consensus.
If the community wants something new or changed, the primary discussion is usually elsewhere. However the task generally needs to end up at Phabricator for tech-action. Depending on what the task is, a common case is that Foundation wants evidence of community consensus for that task. There are a lot of tasks that have been "open" for years, but simply haven't had any programmer time devoted to them. I also have an interesting link to some community-consensus-requests that were rejected by the Foundation.
The thorny issue is when the Foundation wants to deploy or change something major, and the community considers it harmful. Everyone has good intentions, we all want to work together, but sometimes the two sides have different perspectives on the best course of action. We have been unable to agree on a process or answer here. I could list some conflicts that have ended in various ways, but this post would get unreasonably long. There has been longstanding and very serious tension between the Foundation and the community on the question of deployment-against-consensus. The question itself leaves us in a state of constant and toxic tension, even in the absence of any active dispute. Both sides believe they have moral authority, and as a practical matter both sides have the power to catastrophically nuke each other if a conflict ever escalates out of control.