User talk:Katherine (WMF)

Archives

---

1, 2, 3

Response from the Wikimedia Cuteness Association

Dear Katherine, Today you requested the Wikimedia Cuteness Association in your keynote session to endorse the Wikimedia 2030, the 2017 movement strategy direction. We are happy to inform you that both the Wikimedia Cuteness Association and the Wikimedia Cuteness Advisory Committee endorse the strategic direction. We just published an official statement at: Wikimedia Cuteness Association/Vision for Wikimedia 2030.

Nothing can hold you back any longer from signing the section Users that support cuteness in the Wikimedia movement on the page Wikimedia Cuteness Association. Do you also want some stickers? Wendy the Weasel (talk) 01:47, 12 August 2017 (UTC)

Flow - Has the WMF reversed position regarding uninstalling it?

In November 2016 Flow was amicably uninstalled from EnWiki[1] by request from the community. (We skipped running an RFC, everyone agreed the RFC would pass.) People were happy with how helpful and cooperative the WMF was.

In February the WMF published the results of a survey on Flow.[2] The survey found 38% support for Flow, however those results were inflated. The WMF targeted a massive number of personal survey invitations to Flow-enthusiasts. Based on those results, the survey report recommended that the WMF resume development of Flow, and that the WMF pursue expanded deployment of Flow. Flow development was then added to the Quarterly schedule.

In March Flow was uninstalled from MetaWiki[3] by RFC request (87% consensus).[4] People were happy with how helpful and collaborative the WMF was.

There is currently an RFC underway on Commons requesting Flow be uninstalled.[5] It is still early, but it looks like it is heading to consensus.

There is currently discussion at German Wikipedia to open an RFC to uninstall Flow.

However recently some members of the staff have suggested that the WMF has reversed position. They suggest that the WMF may no longer be willing to uninstall Flow from communities that don't want it. This has people concerned and upset. It also seems to be a very strange position, the WMF would spend more time talking about why it won't uninstall Flow than it would take to actually uninstall Flow.

Could you please confirm the WMF's position? Is the WMF willing to uninstall Flow from communities that don't want it? Thanks. Alsee (talk) 20:34, 13 September 2017 (UTC)

Hey Alsee,

Katherine is traveling at the moment, and she asked me to reply on her behalf as the product manager for the Structured Discussions tool (formerly Flow).

As you say, we at the Foundation accepted the earlier requests from the English Wikipedia and Meta wikis to remove the Structured Discussions tool from their wikis. On the Commons RfC that you started, I indeed said that "I have decided not to de-install this software from this or any other wiki without a solid technical reason for doing so." I explained there briefly why: custom configurations for each wiki slightly slow down the sites for every reader and editor, and they complicate Ops' work, which is a security risk. The greater the complexity of variation between wikis, the more expensive in time, server cycles, and maintenance – and thus, money – everything will be.

I'm sad at your characterisation of the survey of users of the system as "inflated". We at the Foundation have a duty to support our users across our many projects, including around tools more suited and acceptable to some than others. When seeking improvements to the upload tools, we survey users from Commons rather than some conceptually balanced sample of all Wikimedians. When we want to support the OCR text features of ProofreadPage, we talk to Wikisource users. Similarly, when we wanted to know how the structured discussions system was working for its users, we sought the views of those who had experience with it, and their responses convinced us of the need to resource some improvements.

We published the initial draft of the annual plan back in April, and advertised it quite widely for community input. No one objected to (and several were happy with) our proposal therein to improve Structured Discussions during that process. I consider our annual plan a sort of "contract with the communities", and it's important to me that when we say we will do things, our communities can expect that we keep to our commitments in that plan.

Jdforrester (WMF) (talk) 23:04, 13 September 2017 (UTC)

Illogical answer. The goal of having a more consistent configuration can more easily be achieved by uninstalling Flow from all wikis and activating it only where needed. --Nemo 10:59, 29 September 2017 (UTC)

Quora

Are you aware of Quora Keeps the World's Knowledge For Itself? --Nemo 11:01, 29 September 2017 (UTC)

Forbes article on the future of Wikipedia

(copied from Wikipedia Women in Red talk page)

• I have just read with interest Katherine Maher's article "How Wikipedia Changed The Exchange Of Knowledge (And Where It's Going Next)". While the general objectives for the future are perfectly reasonable, I was disappointed to see that such little account had been taken of the progress we have made over the past year or so on Women in Red. Maher tells the world, "...right now only 16% of the 1.3 million biographies on English Wikipedia are about women." In fact, "right now", on 1 October 2017, exactly 254,892 (or 17.11%) of the 1,489,788 biographies on the English Wikipedia are about women. (See the latest Wikidata stats presented by WHGI here.) I wonder where the dated figures came from and why no one helped to keep our Executive Director informed of what we are doing. (Strangely Maher does not appear to be an EN Wikipedia user. Perhaps someone could keep her informed.)--Ipigott (talk) 14:25, 5 October 2017 (UTC)

Proposals for policies regarding Staff-community interaction

(Sorry if this really isn't the right place for this. If there's someone in particular who's in charge of these kinds of things, could you please direct me there? Thanks.)

Discussions involving both WMF Staff and community members have been somewhat contentious over the past several years, leading to worsened WMF-community relations and a generally less civil environment for everyone. I don't think this is anyone's fault in particular, but there are several ways in which the WMF may be able to improve things. Three areas in particular in which I think the WMF may be able to reduce friction:

1. When WMF employees participate in discussions, there is usually no indication that the owner of their staff account and their personal account are the same person. This becomes harmful when an employee participates in the same discussion under both accounts, leading to accusations of sockpuppetry and possibly a disregard for any opinions posted from a WMF account. There are legitimate reasons why one may need to switch accounts mid-discussion, for example to indicate participation under a different role, but it is very important for trust and community health that everyone can be certain that two comments from two apparently disconnected accounts actually come do from two different people. One possible solution to this problem would be for a policy to be enacted requiring that WMF employees that may participate in the same area in both a personal and professional role change the signature of their staff account to include their personal username in brackets after their staff username. Possible alternative solutions include changing staff usernames to match personal usernames (though that would likely be a problem for reasons of professionalism), or prohibiting participation in the same discussion under both accounts.
2. When the WMF attempts to gather consensus from a community, things get complicated. Technically, the WMF doesn't have to get consensus to implement changes to software or policy, so when it tries to, reactions from certain community members are sometimes less than positive. It's often unclear whether the WMF intends to actually listen to the community's decision or not. If some community members incorrectly assume that the thread began as a result of someone receiving an assignment to "get consensus" for a decision that's already a foregone conclusion, the discussion becomes less about debating the merits of the proposal, and more about yelling at whichever well-meaning WMF employee is involved, trying to rapidly convince them that going through with it would be catastrophic in rather harsh terms. Certainly, the WMF will occasionally need to try and gather feedback regarding an action without actually committing to do whatever the community decides, but the distinction between the two types of discussions really needs to be clear or else it poisons actual attempts to gather meaningful consensus. The norms of collaborative discussion and consensus seem to essentially break down when there's such a difference in power of the participants. I recommend establishing a policy clearly delineating requests for a community decision via discussion and consensus on one hand, and requests for feedback which the WMF is permitted to disregard on the other.
   (I'm probably a bit overstating how much of a problem this is and how frequently these issues happen. I'm also worried that these problems might make the WMF less likely to engage with the community, which would be really bad in my opinion.)
3. The community needs to know that opinions expressed by WMF employees are their own, and that they were not assigned or pressured into expressing them. We've already had discussions where concerns of this have been raised, leading to multiple accusations from WMF employees accusing community members of discriminating against them because of their employer, with the discussion going downhill from there. These interactions erode trust between the community and the WMF, and make it much more difficult for cooperative discussions to take place.

I know a lot of these issues sound like they could be fixed by people being better at Assuming Good Faith, but we have to work with what we have, I suppose. Hopefully the situation can be improved. --Yair rand (talk) 00:48, 24 October 2017 (UTC)