Talk:Community Liaisons/Wikimania 2015

From Meta, a Wikimedia project coordination wiki

Prioritization[edit]

I wanted to start with this topic, as it's important. In the session, I got the impression that the participants initially meant prioritization as in "what does the Foundation decide to build" - on an overall product basis. After speaking with some of the product teams in the past week, they are looking at it on a smaller scale - two week sprints, and how are bugs and features within individual products prioritized and how can communities participate in that method as well? We can use examples from the VE bug triage meetings for this smaller scale, and can break this down from overall to more micro decisions. -Rdicerb (WMF) (talk) 23:59, 6 August 2015 (UTC)[reply]

Members of the community not familiar with the Community Engagement (Product)/Process ideas page may find some useful ideas there, in this instance at the section on Prioritization process. Rogol Domedonfors (talk) 18:52, 7 August 2015 (UTC)[reply]
  • Absolutely the participants or at least the non WMF ones like me meant prioritising what the WMF decides to build. I can understand that some in product development would prefer the status quo where they decide what the community needs. But if we want to get developments that the community actually needs, if we want to prioritise more suggested improvements than any one person could realistically evaluate, and above all if we want to go back to the winning formula of this being a volunteer led community, then at least some of the IT budget needs to be allocated for projects that the community chooses. E.G. like this Grants:IdeaLab/Community prioritised IT developments WereSpielChequers (talk) 14:13, 11 August 2015 (UTC)[reply]
    • Understood, WereSpielChequers :) - I am passing this feedback to other team members in product development and will push for a more transparent decision-making process involving community - this was one of the key takeaways from the roundtable session. Technically, anyone can suggest a product or feature, from a reader or long-term contributor or the ED, but there is no clear decision-making process for deciding whether the idea is even considered and based on which criteria, and we need one. Prioritization is ideally be based on a variety of factors - alignment with the movement's mission and strategy, community request, technical feasibility, data-informed decisions (I prefer this to "data-driven"), among other factors. -Rdicerb (WMF) (talk) 23:00, 12 August 2015 (UTC)[reply]
      • Data driven would be good, but we often lack data. Take for example the various longstanding proposals to reduce the number of edit conflicts on wikipedia, if we had stats as to how often edit conflicts take place and how often they are a predicter/driver of newbies leaving, then I suspect we would either find it going to the top of the queue for IT investment. Or of course the data could prove me wrong and if so I and others might stop raising it as the most obvious low hanging fruit. But since we don't even have a public log of edit conflicts it is difficult to prioritise this one, and has been since at least 2007. WereSpielChequers (talk) 12:13, 18 August 2015 (UTC)[reply]
        • Thank you for raising this very valid point! You've had me thinking about edit conflicts, and yes, you understand them to be a big issue because you either hear about them or experience them yourself, but lack of data causes you to only be able to go on your hunch. This being said, Now I want to ask around to see what kind of data we currently have on edit conflicts. If we don't have what's needed to understand the scale of that problem, the next step as I see it would be determine how we prioritize a research and data request to figure it out - because gathering this data also has a cost, so understanding that better helps to prioritize, as well. -Rdicerb (WMF) (talk) 18:43, 20 August 2015 (UTC)[reply]
          • I've experienced edit conflicts myself many times, but I know how one can usually resolve them. I've run real life training, both outreach editathons for newbies and traditional editathons for more experienced editors, so I've shown people how to resolve edit conflicts in real life. I've also seen editors online complaining about losing their edits because someone has tagged or categorised the new article they had just started; and while we haven't had an editor survey in far too long, as I remember it the last one did have a question as to why people had left, but it didn't differentiate between whether they had been bitten by the software or other editors. So I like to think my experience is more than just a hunch. I'm aware that two of our sources of new editors are people creating new articles and people editing trending topics, and that those are areas where newbies are highly likely to get edit conflicts. As an example, on the night Sarah Palin was announced as John McCain's running mate the article on her peaked at 25 edits per minute. It would be fascinating and probably quite sad if we knew how many edits had been lost in edit conflicts. WereSpielChequers (talk) 19:49, 23 August 2015 (UTC)[reply]
  • I've asked around on Prioritization and there is some documentation as part of the Team Practices Group, and it is being discussed. In the meantime, Community Tech has posted their criteria for prioritization, which I think gives a different and perhaps clearer example of prioritization. I'm sure there are more things posted - it just isn't always easy to find (or perhaps it's just me). :) -Rdicerb (WMF) (talk) 22:39, 31 August 2015 (UTC)[reply]
Thanks for that. I invite you and your team to think very hard about your last sentence -- if you yourself do not find it easy to locate information, how hard do you imagine the volunteer community find it: and do you think that you, your team and your colleagues have the responsibility to take some action to rectify that situation? Rogol Domedonfors (talk) 21:23, 6 September 2015 (UTC)[reply]

Feedback channels[edit]

"Where?" and "Who?" were indicated as the primary points of confusion in giving product feedback. With so many places to communicate, and a lack of clarity around 1. What individual staffer's roles are, and 2. who is watching which channel, it's hard to know where to most effectively give feedback. There's also the problem of people's personal preferences - some people don't use IRC, some prefer to stay on their home wiki. Staff may have to decide on places we can/will communicate and places we can/will not (I am aware of the irony of creating this new page in which to post this). -Rdicerb (WMF) (talk) 17:27, 7 August 2015 (UTC)[reply]

Indeed, there appears to be related material at
all of which might be relevant to trying to coordinate community discussions. Rogol Domedonfors (talk) 06:15, 10 August 2015 (UTC)[reply]
There are many more than that, as well! :) Keeping this particular feedback request scoped to engineering and product development cuts out some of these pages, but indeed, adds many more in engineering. Something that was requested during the Wikimania session was a CRM or centralized place to give *all* feedback. I'd love for the person who suggested this to please give additional explanation if they are comfortable doing so on this page, but I think given the 800+ individual wiki projects, language barriers, etc, that figuring out how to do this is quite challenging.
Tech/News is now the responsibility of community liaisons, and there is the Engineering portal of the Tech/News portal which lists all of the individual product and engineering teams, leading to their pages. I wonder if this could feasibly be considered a centralized hub of information - though I don't think it would act as a centralized hub of collaboration, and I think part of the problem is that it's so easy to get lost in a sea of information (I do this frequently). But I wanted to throw it out there as a possibility of developing it into a central hub - at least for engineering and product initiatives. Thoughts? -Rdicerb (WMF) (talk) 21:24, 10 August 2015 (UTC)[reply]
I was not at that meeting so can hardly speak for the person you mention. However, as I mentioned to your Senior Director recently, it is hardly the province of the community to give you detailed instructions in how to do your job. All that the volunteer community can reasonably be expected to do is to articulate their requirements, not your solutions. What I believe success might look like would be, as I have stated before, would be a small number of well-known, well-publicised, actively managed portals where community members may receive prompt, clear, usable, authoritative responses to questions, comments and suggestions, with named staff taking responsibility for acknowledging contributions, giving answers promptly where possible, owning more complicated discussions and ensuring that they are steered through to resolution. The dialogue should be one of genuine open communication and collaboration on all sides, without point-scoring, debating tactics, information-hiding, back-channel decision-making or sulking. Do not mistake conversation for decision-making, or saying things for doing them; do not raise expectations without the ability, authority and intention to meet them: have responsible people make promises, not predictions, and keep them, or acknowledge failure to do so frankly, fearlessly, promptly, openly; celebrate success, apologise from failure and show lessons learnt. Above all, communicate clearly, quickly, effectively, regularly and frequently; follow through on whatever you say. Share your working in places where community members involved and interested are likely to see it and share in it, or at least point to it from those places. Accept the community as partners not adversaries. Rogol Domedonfors (talk) 21:24, 11 August 2015 (UTC)[reply]
Another issue you will need to address is that of language. While it may be sustainable to translate relatively stable documentation into numerous languages, consultations involving working discussions need a faster timescale. While I naturally assume that the working language would be English, that is not quite a given. You need to decide which languages you can sustain near-to-realtime translations from: probably only a handful. Are there automated or sem-automated tools that can help? Are there new ideas for resourcing, recruiting, recognising, rewarding and retaining the additional translations you are going to need?. No doubt you already have data on which are the most effective languages to conduct business in, as that information is already needed across all areas engaging with the community at a strategic level, and preliminary scoping on the resource implications.
More on resourcing. Currently WMF does not have the staff required to clear the backlog of surveys and consultations. Should you be starting any new initiative before that backlog is cleared? As noted above, there is a long list of pages, some with quite long-standing unresolved issues. Would it not be best to prioritise those? Rogol Domedonfors (talk) 18:38, 12 August 2015 (UTC)[reply]


Language and translation; MediaWiki vs. localization[edit]

Rogol writes above "Another issue you will need to address is that of language. While it may be sustainable to translate relatively stable documentation into numerous languages, consultations involving working discussions need a faster timescale. While I naturally assume that the working language would be English, that is not quite a given. You need to decide which languages you can sustain near-to-realtime translations from: probably only a handful. Are there automated or sem-automated tools that can help? Are there new ideas for resourcing, recruiting, recognising, rewarding and retaining the additional translations you are going to need?. No doubt you already have data on which are the most effective languages to conduct business in, as that information is already needed across all areas engaging with the community at a strategic level, and preliminary scoping on the resource implications. "Rogol Domedonfors (talk) 18:38, 12 August 2015 (UTC)[reply]


I hope it's OK that I copied your second paragraph to this section, Rogol :)

Where possible, the team would like to localize to a project's language. If there is a Meta or Mediawiki page, it can be translated by volunteers if requested. The team has used this to translate messages that either live on either of those projects or go out via mass message (for example on users talk pages). The team has also used TranslateWiki to hold translathons for document translation contests. As for the most common languages, we do try to post in those languages if we can do so in a reasonable time frame. But as to the point about faster timelines - yes, sometimes getting the message posted quickly is necessary.

There are some semi-automated tools which can help (if one is referring to Google translate or similar software) but those are much better for translating from a language you do not know, into a language you already know.

The statement made at the roundtable discussion was in reference to individual language projects where the team doesn't speak the local language. One of the liaisons' hiring requirements in the past year has been the ability to read and write in languages other than English (and has hired as such), but of course, the movement covers many more languages than we're able to cover and need to communicate with! It was also noted that Stewards speak many languages and are known throughout the projects, and having met several Stewards who have helped the team with projects recently, it would always be great to have theirs or translations volunteers help, wherever possible. -Rdicerb (WMF) (talk) 00:20, 13 August 2015 (UTC)[reply]

This is not quite what I was talking about. Firstly, for many things of concern to the community as a whole there is no such thing as a "project's language". Social aspects spanning projects, such as accountability, expertise, conflict of interest, civility, censorship, copyright, child protection for example, are not project- or language-based, although they may well be cultural, and hence positively require a complex cross-cultural and cross-language discusion. Technical issues such as tools for vandalism detection, complex or novel rendering, data curation, are inherently language-independent. So segregation by language does not work.
More seriously, perhaps, is that this reponse seems to assume that communication is one-way. We need mechanisms for discussion, which in turn requires the free, frank, effective and timely exchange of information and views across language communities. That is going to require a step-change in the way translation is done. It's a complex and challenging task, but a necessary one. It will require careful research, innovation, planning and implementation. Rogol Domedonfors (talk) 17:20, 13 August 2015 (UTC)[reply]
Your point around technical tools being cross-cultural is well-put - yes, many of the problems users need to solve through tools have cultural elements and may be specific to that individual community. I began with the challenge of simply being able to communicate on that projects' language, that's one step and one problem to solve of many.
The original point raised in the roundtable discussions is that "Apologies for posting in English" on an individual project (just as an example, let's say Russian Wikipedia) can mean that a message in English beginning with that phrase might not be read. That was important for the team to hear, and worth thinking about. There's also the challenge that we have limited time - in team resources, in needing to communicate and collaborate with different communities. I wonder if one thing we can try to do is have several different community members in each project who are able to act as an ambassadors, to help get word out and give advice on translations, areas where communities tend to communicate on-wiki, etc.
That leads to one of the points from the roundtable about volunteer engagement, which is its own section (I'll start that next). -Rdicerb (WMF) (talk) 21:44, 17 August 2015 (UTC)[reply]
  • This also appears to be a current issue for the Community Tech team, presumably you will liaise with them: mw:Talk:Community Tech team#Current activities. Surely it cannot be novel? Rogol Domedonfors (talk) 07:23, 31 August 2015 (UTC)[reply]
    • I have a team member who is embedded into that team (well, part time - he also is the new lead on Tech/News) - so of course, CLs liaise with them! :) You are absolutely correct, it isn't a novel problem, but seems to be a universal challenge - I'm not sure that there is technology which fully supports immediate, multi-lingual translations. Google Translate and other machine translations are far from perfect (though they are getting better), and the AllOurIdeas system, which has many positive attributes for weighting and prioritizing feedback, is less advanced on the multi-lingual front. Getting support from volunteer translators is time-consuming and while those who translate for fun are highly valued, their services are constantly sought for multiple projects (which I also think must be a universal issue?). I keep thinking of ways to manage it, but there does not seem to be a silver bullet. I'm always happy to be wrong about something like that, but so far I haven't seen a truly streamlined solution. - Rdicerb (WMF) (talk)

┌─────────────────────────────────┘

Getting community support[edit]

Two main statements represented:

  • Recruiting more volunteers is recommended
  • It is then identified that if there is a community request that the Foundation then undertakes, in the past the WMF has not included communities very much in the product development process, and has sometimes resulted in *not what the communities want*.

— The preceding unsigned comment was added by Rdicerb (WMF) (talk) 21:56, 21 August 2015 (UTC)[reply]

These sound like the rationale for setting up the Community Engagement (Product)/Process ideas consultation, which was started just over a year ago. It would be interesting to hear how you propose to respond to the statements which were made at Wikimania 2015 and also to hear the extent to which you would incorporate the results of your analysis of last years consultation into your response. Do you think things have moved on in the last twelve months? Will there be some new actions? Rogol Domedonfors (talk) 16:13, 23 August 2015 (UTC)[reply]
I thought I had responded to this last week, and now I see that that is not the case! My apologies (and thank you for signing for me :) - Let me clarify the /Process ideas page - it was set up (not by me or anyone on my team) to be a rather open-ended, catch-all for ideas. I was told about it after it was started, so I didn't have an opportunity to think through the formation, and quite honestly, the feedback got away from us! I was about 4 months into the job and was still on a very steep learning curve, and there were a few other things happening at the time. I'm not saying this to make excuses, but think that that may set the stage for where *I* was at the time of this. Also, planning conversations takes time and energy, and I need to put team members on it (which means disrupting their work, and the work of the teams they work with). We did and continue to watch the page, but it's by no means a formal consultation (which have start and end dates).
"Do you think things have moved on in the past twelve months? Will there be some new actions?" I'm not sure that my response is all encompassing, but I'll start: The team is engaging new and different users: VE Survey, in which CLs specifically reached out to 1. users who use VisualEditor more than other users and 2. users who have given us feedback on VE in the past. The Editing team has been holding public meetings to go through potential Phabricator tasks. Product teams also have been doing A/B testing, results are posted, the team has supported discussions around turning on products, and also has or will hold discussions about whether and how to build other products in the future. I think the true challenge is writing it all down into a cohesive step by step process :) -Rdicerb (WMF) (talk) 23:35, 1 September 2015 (UTC)[reply]
Goals that I want the team to keep building on: 1. Talking to the people that a particular product affects (like with the VE Survey) - essentially, bringing in a wider range of input, and 2. being able to write down a complete, comprehensive product lifecycle in plain english so that non-technical users understand what's going on and how they can engage and so that it can easily be translated. Working on it! -Rdicerb (WMF) (talk) 23:43, 1 September 2015 (UTC)[reply]
Any progress with that second goal? Rogol Domedonfors (talk) 22:15, 23 February 2016 (UTC)[reply]
Hi there, as you may be aware, the Product Development Process is evolving, though the "plain english" angle really isn't there yet. Drawing this to the attention of @WMoran (WMF): and @Qgil-WMF: to consider when/how to acheive this (it may be worth considering moving the conversation to the talk page there as well). -Rdicerb (WMF) (talk) 20:35, 29 February 2016 (UTC)[reply]
Additionally, and as to not mistake my orignal intention - when I wrote "plain english" that perhaps indicated a dumbing-down quality that isn't appropriate and which I didn't intend. It might be better to provide definitions and describe the process with clarity, which is actually more the intention. -Rdicerb (WMF) (talk) 20:47, 29 February 2016 (UTC)[reply]
We are working on a view of the Product Development Process from the perspective of the communities that should provide "a complete, comprehensive product lifecycle in plain english so that non-technical users understand what's going on and how they can engage". See phab:T124022 and its blocking tasks.--Qgil-WMF (talk) 20:55, 29 February 2016 (UTC)[reply]
Thanks for that, let us hope it comes to fruition. Rogol Domedonfors (talk) 05:22, 1 March 2016 (UTC)[reply]
Just to close this particular loop for the record: phab:T124022 was closed as "Declined" on 14 June 2016. Rogol Domedonfors (talk) 20:48, 14 July 2016 (UTC)[reply]
That task was declined as formulated only because that "view of the Product Development Process" is now mw:Technical Collaboration Guideline. The work continues and is one of our annual goals.--Qgil-WMF (talk) 07:23, 2 August 2016 (UTC)[reply]
Thank you for explaining that. It is hard to keep track of such important matters by scanning Phabricator. Rogol Domedonfors (talk) 21:34, 2 August 2016 (UTC)[reply]

Humanity and personalizing[edit]

Less about the avatars (it's already explained on the content page), more about the face to face meetings, which don't scale as well on a worldwide basis. The WMF does conduct public meetings, most often in the form of IRC Office hours and bug triage meetings within VE, though product teams could standardize that - which would include using a system like WebEx or some other way for anyone to call in (there are often free numbers per country). More opportunities for live interaction would be helpful, but I personally have noticed waning participation in the two methods I've mentioned here (often 2 or 3 people in the VE office hours are participating (and some WMF staff), and a few people came to the bug triage meetings, but have since stopped. Having live meetings, even if virtual, offer means of humanizing the experience and ability to get instant answers - at least, I think it does. -Rdicerb (WMF) (talk) 22:52, 1 September 2015 (UTC)[reply]

Historical[edit]

With no substantial changes to the page since last August, and no discussion for three months, I suggest that the time has come to mark this page as {{historical}}. Rogol Domedonfors (talk) 21:31, 30 May 2016 (UTC)[reply]