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.
What the title says. You can read my candidacy on Meta-Wiki, and ask questions on the talk page!
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!
This is a follow up to my probably depressing blog post on Friday, entitled "Why am I still here?" I think I figured out the answer, it's a lot of different things!
So now that you're here, lets talk about something happy: cross-wiki notifications!
In 2013, notifications were introduced and collected events that users wanted to know about in a flyout. The initial response was that it looked like Facebook (it really did), and anger (well I'm not sure what the right emotion was) that the "Orange Bar of Death" was gone. But the longer term impact has been a significant change to how on-wiki discussions work. One of the new features was that users can get "pinged" when someone links their username in a discussion comment. These days usage of templates like {{talkback}} is extremely rare, and entirely replaced with pinging.
So, cross-wiki notifications. This has been a long requested feature request, and I had actually written an RfC about implementing it long before I was on the team tasked with implementing it (well, technically I was on the E2 team at that time, but history is confusing). Of course, I would be remiss to mentoin that most editors already have a cross-wiki notification system through their email inbox. Regardless, some people are so excited they didn't even read the announcement. ;-)
However, there were some limitations in the architecture that made expanding it for cross-wiki usage difficult. The most significant was that the formatting system was designed for specific types of notifications, hard to extend, and most importantly, difficult for developers to understand. We probably could have hacked our way around it, but the extensability was going to be a serious problem. And if we were going to touch some code, we should leave it better than we found it. :)
So, what to replace it with? I came up with a presentation model system that every notification type would implement. This made it much easier to follow instead of the old data-driven style of formatters. We also built an API (sorry, logged in users only) around it, so the frontend code can handle all of the display, and not have to parse out HTML to figure out the notification icon (yes, it used to do that :().
So now...going cross-wiki. We effectively had two approaches we could do, the first being created a central database table that all notifications went into, and then having each wiki read from it. This provided some logistical problems like checking revdel status, page existence, and local message overrides. The other approach was to make API requests to other wikis, and then merge the output into the flyout. We ended up going with the second one (cross-wiki API requests) after seeing crosswatch in action, which used the same strategy for its implementation of cross-wiki notifications.
We created a database tracking table which contains the number of unread alerts and messages you have on each wiki, so it would be known on what wikis to query notifications for. We also realized we could make these requests client-side (using CORS) for now, and move them server-side later.
And that's pretty much it. There were also some significant frontend changes, like converting it all to use OOjs UI, but I didn't really work on those, and can't speak much about them.
So, go to Special:BetaFeatures on your favorite wiki, check "enhanced notifications", and let us know what you think! And if it's not on your wiki yet, nag someone in #wikimedia-collaboration on freenode!
Update: The list of wikis where it is available are listed on MediaWiki.org, and it should hit all other wikis by the end of March.
Honestly, I'm not sure. I'm not working at the WMF for the money. And it's not because my job is fun - it stopped being fun a few months ago. I'm mostly still here because I don't really have anything else to do right now. I've been doing this for nearly 3 years now...and even though I have other plans lined up in a few months, I'm kind of a lame duck right now.
I'm embarrassed at everything that's gone on. I don't want to tell my friends that the WMF is all screwed up and not going to get better. I don't want to have to explain how after I praised how all of my work is public and transparent, that our organization no longer is.
The whole Arnnon situation never really sank in for me. It was mostly surreal, with me thinking that there was no way they'd actually let him stay on the board. All the right people spoke up, signed the petition, and then he was removed. The process worked! Not at all. The excuse of not knowing about it because they didn't use "google.com" is ludicrous, that I don't even know what to say about it.
It greatly frustrates me, and upsets me that my friends are in danger of having to leave the country if they lose their jobs, and can't speak up because of that fear.
Honestly, I don't understand why the current leadership hasn't left yet. Why would you want to work at a place where 93% of your employees don't believe you're doing a good job, and others have called you a liar (with proof to back it up) to your face, in front of the entire staff? I don't know everything that's going on right now, but we're sick right now and desparately need to move on.
I love, and will always love Wikimedia, but I can't say the same about the current state of the Wikimedia Foundation. I've been around for nearly nine years now (nearly half my life), and it feels like that world is slowly crumbling away and I'm powerless to stop it.
And that's all my incoherent rambling for tonight.
And now for something less depressing and totally awesome, I mostly-finished the first version of the WikimediaPageViewInfo extension, you can see a demo at http://bf-wmpageview.wmflabs.org/wiki/Taylor_Swift?action=info. It's currently going through a security review, and myself and Addshore are going to work on getting it deployed!
Originally posted on Twitter.
MediaWiki now uses PHP [arrays, like, this]: https://gerrit.wikimedia.org/r/271208
Welcome to the future! ...or 2014 ;-)
