User:Jarry1250/interviews

SUL finalisation
'''Sounds like a complicated process. What stage is it at?'''

The plan is to have the brunt of the engineering work completed by the end of this. Of course there will be bugs, minor features that we need to work on but the majority should be done the. the work at the moment comprises four different streams:
 * We've created, tested and deployed the GlobalRenameUser extension (which allows stewards to rename all global and local accounts with a given name simultaneously). It's designed to work in a post-finalisation world – if there are conflicts, it will error out. Without it, local renames would break finalisation. And that's finished.
 * A request-a-rename form. There are two use cases here. If I'm on a small wiki, and I (for whatever reason) have a local only account, then it might be that I can't keep that name, and I'm told of that in advance. But at the moment, it's ridiculously complex to request a rename and nipping the problem in the bud by avoiding a forcible rename. Without voluntarily renames, there could be as many as 4.3 million forced renames, with considerable administrative overhead. Basically this will streamline that process, and save stewards a lot of work. The second use case is for those who have been told they must rename their account.
 * Login with old credentials. Although we will make every possible effort to contact users about to be renamed, there's a limit to what we can do – some users do not have email addresses listed, or they may not check their talkpage regularly. This extension will allow them to login with their old username and password. Basically, the tool checks usernames against a list of renames and uses the password supplied to redirect the user. It would then display a very prominent warning that the user had been renamed and link them to the request-a-rename form to pick a better name. We hope to keep these warnings in place indefinitely (but not necessarily forever). The intention is that users switch to using their new credentials as quickly as possible, and they will appear throughout the site under their new name.
 * Global account merge. The use case for this isn't immediately obvious. Imagine that a common username is associated with a dozen or more local accounts, each of which will need to be renamed during the finalisation process. If some of those are actually the same user, it gets tricky to merge them without undoing the finalisation by creating more clashes. That's where the need for a merge tool comes in.

What kind of timescales are we talking?

We want the hard engineering work done by the end of September. By then, we'll have picked a date for the finalisation process itself. After that, we'll need to contact all 4.3 million accounts, and give them time to respond, not to mention giving the stewards, bureaucrats and others in the community some warning. That will take a minimum of three months, I suspect. But I don't want to pick a precise date until I'm sure we can achieve it.

'''Most users will already have global accounts. If I've already got a global account, do I have anything to worry about?''' If you already have a global account, only good things will happen. That is certain. For example, you might not have that name on every wiki, because of local clashes. Those clashes will be resolved. And this is a big issue: new clashes are being created every day.

And for those people who don't, and who might be renamed? We need to be aware of these people's concerns. We can't just throw them in the deep end. But there's no way we can avoid renaming them unfortunately.

VisualEditor
'''Where are we now? What will users returning to the VisualEditor notice most?'''

The VisualEditor is currently on by default on 160 Wikipedias and opt-in on a further 127, including the "big four" wikis of English, German, Dutch and Spanish. The remaining wikis are those where it can be difficult to enter text using conventional methods, such as Arabic and Bengali. On these wikis, our support for alternatives is not good enough yet to make a deployment worthwhile. Indeed, a lot of our recent work has been focussed on creating the infrastructure required to support those wikis, rather than working on [wiki-specific] issues per se.

In feature terms, we're in a good state. We've had lots and lots of improvements, and I've been spending my time here at Wikimania showing people things that they can do right now. And they say "I didn't know it could do that". Of course then we have a discussion about further improvements we can make. New versions roll out each week -- new features, bug fixes, sometimes small, sometimes big. So for example there was a lot of disquiet about VisualEditor not showing HTML comments -- and that was pretty simple in the end to [fix]. And now users can indeed read them. That's an example of a small change from our end I know is important to editors. On the bigger side, there's lots of really strong improvements to citations and references generally. So for examples, there's a lot of new stuff about adding them based around the four biggest citation templates on the English Wikipedia (cite web, cite journal, cite book and cite news).

'''Still as about optimistic about the potential for VisualEditor as you were this time last year? What does the future hold?'''

If anything, I think we've proven that the VisualEditor has created a much easier editing experience for a lot of users. It has now been deployed by default on a lot of wikis recently without significant breakages. We did have one major bug that caused some corruption, but we managed to revert that within an hour, and the community concerned was very understanding. We're very focussed on improvements for end users that really do make editing easier, whether editors use the VisualEditor or not -- I've also taken responsibility for the wikitext editor, so that improvements to one editing interface transfer to the other, and users get a consistent experience. That [kind of consistency] has already been done on mobile, with an easier to use design that doesn't mean a big change to people's workflows but does mean less disruption for people who switch between editing interfaces. But there's a lot of testing and feedback ahead for that work.

'''And in the immediate future? Will the team be pushing VE adoption or hanging back?'''

In our plans for the editing team, we said that we wanted to work with the bigger communities (particularly the big four) to discuss what they want to see, so that we can move towards switching the VisualEditor on by default on those wikis. On the English Wikipedia I know there's been some talk about holding a new RFC, but we're keen to get to the actual discussion. I know there were a lot of concerns expressed last year, but I think that people revisiting their concerns will find they have been resolved. But I want people to tell me they're happy, not just assume it, if that's not too much to ask.