in MediaWiki

tagged wikimedia

What is the Crisis?

The following is my answer to a question asked of board candidates in the current ASBS election. I'd like to be able to discuss what I posted without making it look like I'm canvassing or something. You can read what other candidates said on Meta-Wiki.

Q. One candidate stated: "WMF has been going through, for many months now, an important crisis with huge stakes." I think many would agree with this overall statement; however, different people would describe the "crisis" differently. A Trustee's perception of what the problems are will play a huge role in how they approach the position. Can you please share your understanding the events of recent months, and what Board-level problems they expose? Pete F (talk) 17:55, 1 March 2016 (UTC)

There is a significant amount of mistrust and fear within the organization and the movement as a whole. The staff do not trust the board. The community does not trust the board. The community does not trust the staff. The staff are afraid of the community. The board does not even trust itself!

I believe I will have a unique perspective on this from other candidates as a WMF staffer during the “crisis”, so I'll go into some more detail. I do not believe it is worth rehashing the specific events that have happened recently, so I'll try to speak more generally.

The staff do not trust the board. Starting with the November all-staff meeting, an overwhelming amount of staff have lost their trust in the board. When legitimate concerns were presented to the board (many of which are still not, and probably will never be public), the board did not act, forcing staff to bring the matter up publicly, after strongly trying to resolve the matter internally. From what I understand, part of the problem was that one of the main sources of information the board got was from the executive director, which was not a good conduit for passing information along. Jimmy and Alice visiting San Francisco to talk with staff is a good start to rebuild trust, now both sides need to follow through by creating the discussed “ombudsperson” role that reports directly to the board.

The community does not trust the board. The other questions on this page about transparency and minutes lacking detail are simply symptoms of a lack of trust (not that they aren't important, but I'll address them in those questions). Rebuilding trust here will take a while, mostly because the board operates in a different manner than our wikis do. I believe that over the years I have earned the trust of many Wikimedians, whether in my volunteer role or as staff, and hope to bring some of that trust to the board.

The community does not trust the staff. I talked about this in my candidate statement – the community is tired of bad software being thrust upon them, and then fighting to get rid of it. It's not uncommon for me to be reading a village pump or technical page where people will sincerely state that they believe the WMF is actively harming the projects, rather than helping them. I believe that the best way to rebuild trust in this area is to get more people involved in product and technical development. Whether it be individual community members of affiliates participating in developing our software, I think the end result will be significantly better.

The staff are afraid of the community. Some (definitely not all!) community members are openly hostile to staff members, questioning their competency for their job, etc. Part of it is due to the lack of trust and past history, while other community members are just frustrated and are looking for someone to blame, and it technically happens to fall under the WMF's responsibility. The end result is that staff will now draft proposals and plans in private Google Docs instead of public wikis, or discuss things via private email instead of public mailing lists. We claim that our communities are our biggest asset, but the WMF needs to start acting like it means it.

The board does not trust itself. This one seems self-evident based on the removal of Doc James from the board. I do not have much visibility on the current board dynamics, and don't have much to offer in what to work on.

So where does the board come in to all of this? The WMF is in a partial state of dyfunction currently. It is the board's responsibility to make sure the WMF is able to function properly. The board needs to be proactive in rebuilding bridges and rebuilding trust.

All that said, a phrase that's come up recently that I strongly agree with is “change happens at the speed of trust”. There is a huge lack of trust right now, which means that change will happen slowly. That's okay. Trying to push change through too quickly will only cause more mistrust, which we desperately need to avoid.

in MediaWiki

tagged mediawiki, notifications

The future of Echo

Echo (aka "Notifications") is the MediaWiki extension that provides a notifications framework for other features to use, as well as some "core" notification types. It's had a tumultuous history ever since it was deployed to Wikimedia wikis in 2013. To figure out where Echo should go, I think we have to look at its history first.

The initial deployment was pretty rough. The OBOD was gone, but no replacement. Standard APIs like hasmsg=1 didn't work either. The development team (WMF's "E2" team) iterated on those, improved the API integration and added a newer and less obtrusive new messages indicator (while also designing my personal favorite, nerdalert.js). So the time came for the deployment to be expanded to all Wikimedia wikis, at which point nearly the entire development team switched over to a different project (Flow), leaving one engineer to supervise the rollout over all projects. Umm, what???

So we ended up with bugs like "Mention notifications don't work if the sender's signature contains localized namespaces" taking nearly 5 full months to fix. That sucked.

Anyways, Echo was mostly dormant until mid-2014, when the "Core features" (previously E2) team made changes to Echo to support having Flow notifications go in a separate pane in the flyout. Except Flow was barely used at this point, so no one noticed outside of mediawiki.org really. (I was technically on the core features team at this point, but mostly doing Flow API things IIRC). But after a month or two most of the development moved back to Flow.

And then finally after the great engineering re-org of 2015, the Collaboration team (formerly Core features, but you already guessed that ;-)) also started looking at Echo seriously, and starting to fix some of the issues that had piled up over the years, including splitting the alerts and messages flyouts properly, giving user talk messages more prominence, and eventually embarking upon cross-wiki notifications.

Despite barely getting any attention from developers (until now really), Echo remains the most popular and really only successful product to come out of the E2/Core features/Collaboration team. Why?

The most useful feature of Echo is definitely the mention notifications which allow you to "ping" other users. So instead of people having to watchlist giant pages and look through history to see if anyone responded to the one thread they want to follow, they can wait for the notification that someone pinged them while responding. The once widely used {{talkback}} template is now deprecated in favor of these notifications. And for most users, this functionality is good enough. Watchlists really haven't seen any major changes in the past few years (again, until the past month, but that's another story), so something else that can do the job was welcomed by users.

So now we're in the state where we have two overlapping, but not exactly the same features: Notifications and Watchlists. Gryllida has written up an RfC titled "Need to merge Notifications and Watchlist or lack thereof", discussing some of the similarities and differences. Over the next few months I'd like to flesh out the RfC a bit more and work on a solid proposal.

I also wrote an RfC yesterday titled "Notifications in core", which discusses merging parts of the Echo extension into MediaWiki core. I think this is crucial in improving the usability of notifications from both a user and developer perspective, as well as improving the architecture by requiring less hacks. And it can probably be done before the reconciliation of notifications and watchlists.

So, that's where I think Echo should go in the next year or two. I probably won't have time to actually work on this, so we'll see!