On 5 August 2014 11:33, Gryllida <gryllida(a)fastmail.fm> wrote: The roles you describe seem to have a lot of overlap with what we might expect WMF volunteer coordinators / WMF community liaison employees to be busy with. Compare with: * http://wikimediafoundation.org/wiki/Job_openings/Volunteer_Development_Coor… * http://wikimediafoundation.org/wiki/Job_openings/Community_Liaison Do you intend this to be an unpaid team of volunteers doing these tasks, or a end user group (in the Agile sense) that would be supported by employees and may themselves be paid for some activities? Fae -- faewik(a)gmail.com https://commons.wikimedia.org/wiki/User:Fae

On 5 August 2014 12:05, Gryllida <gryllida(a)fastmail.fm> wrote: You mean like the tech ambassadors? https://meta.wikimedia.org/wiki/Tech/Ambassadors One thing to keep in mind is that English Wikipedia is only one of hundreds of projects. The technology and engineering groups generally work at a global level because they affect all projects; it's rare that they're doing something for one project only. There are lots of opportunities for community members to interact and to test software in advance (the "beta" preferences are but one of them) - but when discussing a global project or process or software, the best place to discuss is rarely going to be a single page on a single non-global project. Risker/Anne

Hm. I wonder if the engineering community liason role could be adapted to address the suggestIons here. Also I would like to know what the liasons currently do besides file bug reports and respond to dev process questions, which are good to do but not what I would call strategic change management. I think the role of this department is under development anyway after Rachel's arrival so this is a good time for the questions raised in this thread. I'm pinging Rachel to ask her to comment. MzMcbride, I'm not sure that WMF is overstaffed, but I would like to see more specific performance metrics for some groups. The FDC commented on this as well and I hope WMF is taking that to heart. I'm pinging Garfield for comment on that portion of this discussion. Pine On Aug 5, 2014 5:53 AM, "MZMcBride" <z(a)mzmcbride.com> wrote:

With due notes that I just yesterday updated my nick and my e-mail, and I'm the one who started this thread; On Wed, 6 Aug 2014, at 06:58, Quim Gil wrote: 99% of users of Wikimedia projects don't /know/ about these tools. That's the problem, and your response is not reflecting it. Listening to me (or other mailing list members) here or in your personal e-mail is not the way to go, as mentioned in my earlier line. I had trouble talking with Nemo. He doesn't go in lengthy discussions about development and explaining things on IRC. Is he more willing to follow-up and give examples over e-mail? Probably; I have not tried. On the plus side, I've had infinitely nice experience with him regarding translations of documentation. Related message: http://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073696.html That is correct, and is the problem. Those, and IEG/PEG grants, scratch only a very small part of the userbase, and only their bigger projects. The problem is with engaging a vast majority of userbase in scripting the software to meet their personal needs. See, for instance, with Firefox, customizing is exceptionally easy using existing add-ons or writing your own using the Jetpack. These are well-documented technologies and they're also, unlike what happens at Wikimedia projects, well advertised to end users. "Would you like to see MediaWiki as openly customizable as Firefox?" Wikimania people are a tiny part of the userbase. _How_ would you do what you're talking about there? This is not mentioned in the abstract, even though the problem raised is similar. Community volunteers could be featured for their technical work, and get rigorous feedback from community. If some of them start doing it contrary to community expectations, there should be means to clearly display that (and kick them out if they start doing rubbish and fail to hear the said feedback). -- This is very unclear and unspecific. I would expect others to come up with a specific mechanism for such cases. Svetlana.

On Tue, Aug 5, 2014 at 7:09 PM, Pine W <wiki.pine(a)gmail.com> wrote: Garfield is not really the right person to ask about this. A CFO (or at least, our CFO) doesn't set or monitor performance metrics for individual teams other than his own. Regardless, I think it's an important topic Pete. Having more community members comment on and question the yearly or quarterly goals for teams in general would be step toward the kind of feedback Gryllida mentioned in the start of the topic. If anyone is interested in digging in to this more, there's a thread on the Talk page of the WMF engineering goals for 2014-15 document, which is at https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals. (There are also goals for other teams of course, but since this is an engineering-related thread I wanted to focus on just that.)

On Wed, Aug 6, 2014 at 7:06 AM, Pine W <wiki.pine(a)gmail.com> wrote: You don't need to go through the FDC to talk to teams about their goals. You can just go talk to them via the wiki, or a mailing list.

On Wed, 6 Aug 2014, at 15:44, Steven Walling wrote: This activity should be redundant. If someone in the Foundation fails to see the community, it should be fixed.

Meta comment: if our common goal is to increase collaboration, then we need to excel ourselves in this collaboration precisely. If we minority of tech-aware contributors are being confrontational between ourselves, then we can only expect to nurture more confrontation than collaboration among the new tech contributors we aim to engage. So please, let's enjoy this conversation and let's help each other finding better ideas to improve this problem we all want to solve. On Wed, Aug 6, 2014 at 4:01 AM, svetlana <svetlana(a)fastmail.com.au> wrote: Yes, I agree. Can we do better? I think the core of the problem is how to increase the participation of tech-curious contributors, and how to structure it in a way that informs, influences, and actually joins the development process effectively. How can we increase the participation in technical matters among Wikimedia editors and readers? For some thoughts on this topic, see https://commons.wikimedia.org/wiki/File:Wikimedia_technical_volunteer_outre… https://www.mediawiki.org/wiki/Project_talk:New_contributors#English_Wikipe… Increasing participation by volume of participants is a goal per se. However, this participation needs to be somewhat structured in order to become efficient. For instance, having "more Tech Ambassadors" is good, but wouldn't it be better if we all knew which Wikimedia projects and areas of expertise are they covering? I even think that having a sense of meritocracy among tech ambassadors would be useful, just like it is useful at some point to know who is an official maintainer of a repository, who has been granted permissions to merge new code. Am I referring to the Technology Committee that Pine is proposing? I don't know. What I know is that tech meritocracy (and any meritocracy) works better when it emerges from the grassroots, and therefore I'm skeptical about any process that would start with a mandate from the Board or with a WMF goal. There are many smart, productive, and dedicated technical volunteers in our community. In relation to the problems we are describing here, they have an understanding, an experience, and a vision that most board members and WMF employees can't match. I wonder what do they think, what would they do? And I wonder how can the rest of us help them.

On Thu, Aug 7, 2014 at 3:33 AM, Quim Gil &lt;qgil(a)wikimedia.org&gt; wrote: Fwiw. My approach for this is based on simple fundamental properties of the interface (which I believe to be responsible for the success of wikis in the first place). Based, at least in part, on my own experience, I believe the key to giving new contributors a path to gradually increasing involvement is <takes a deep breath> to have everything be done by directly editing wiki markup. Seriously. This has been my experience. You start out doing some very simple things like correcting a misspelling. Because you are actually editing the wiki markup, as you correct that spelling error you can see how other wiki markup is structured, that others have written. As you get more involved, from time to time you choose to exercise some slightly more advanced technique you knew was possible, and had some broad notion how to do, because you'd seen that others were doing it, and you'd seen how they did it. And so on. You may notice that this vision of what promotes gradually increased participation is in direct conflict with the idea of Visual Editor. My premise implies that Visual Editor undermines (incidentally, for this thread) the core infrastructural advantage that makes wikis a successful concept. In order to extend this gradual-advancement path into the sharing of community expertise in how to perform technically complicated tasks --- which I see as a major need of all the wikimedian sisters --- I had the idea of creating a set of templates (thus, keeping things within the purview of wiki markup) for adding interactive elements to wiki pages: text boxes, radio buttons, menus, and *buttons* that pass the contents of those text boxes to "actions" that do things with them: feeding them into other pages as input-element content, as template parameters, and as new (or initial) content in page edits. I've been at this for... I guess it's three years now, creating these basic facilities with a mix, under the hood, of wiki markup, javascript, html, and (recently) lua. Although it was obvious from the start this would be most efficiently done as a wiki extension, I reckoned (sorry to be blunt) the development process for wiki extensions was stacked against anything that doesn't cater to central authority's notion of what would most benefit Wikipedia. (Yes I worded that deliberately, though cynically; I've acquired my cynicism by watching what actually gets done over the six or seven years since I got sufficiently involved with wikimedia to notice.) Fwiw, after three years, I'm just about ready to start trying to use my tools for some serious applications; yonder <https://en.wikinews.org/wiki/Help:Dialog>. Pi zero

On 7 August 2014 00:56, MZMcBride &lt;z(a)mzmcbride.com&gt; wrote: They've got two roles. They've got to try and get the developers to try and introduce their changes in the way thee community accepts. They've also got the role of keeping the community informed about what is going on. Given that the developers want their software to be accepted (and lets face it the community has a conservative element) there is a lot of pressure in the direction of PR tactics. -- geni

David Gerard wrote: Yep. At least one of the on-wiki comments by a liaison made me do a double-take as it had the tone of "your call is very important to us, please stay on the line and a representative will be with you shortly." But I don't think this is about people shooting the messenger, exactly. With VisualEditor, it was a rush to deployment. And this has been fully acknowledged as a mistake. But the Wikimedia Foundation took the lesson to be that it simply needed to move a bit more slowly, not more smartly. For comparison, we now have MediaViewer, which moved through as a beta feature. They say MediaViewer may one day be as feature-ful as the file description pages we've had for a long time (editing capability, oh my!). It makes little sense to create hobbled file description pages in JavaScript rather than addressing the actual issues that file description pages have, but this point seems to have gotten completely lost somewhere. I think the common theme here is forcing software upon wiki communities. But I see VisualEditor and other efforts as distinct from far more questionable features. We're occasionally, though repeatedly, seeing resource investment in features that nobody asked for or wanted, and this can be frustrating. This frustration is certainly compounded when these features are forced on users, but the two issues (a rush to deploy features versus resource allocation for unwanted features), while sometimes intertwined, can certainly also be discrete. Related: https://en.wikipedia.org/wiki/Special:Permalink/620310885#nyb MZMcBride

On Fri, Aug 8, 2014 at 2:47 AM, MZMcBride &lt;z(a)mzmcbride.com&gt; wrote: Sure, sometimes in a liaison role all you're able to say is "we'll get back to you". But that doesn't really characterize the day-to-day work that Rachel's team is doing in supporting the development of products. Part of the reason we brought this group closer together with development teams is precisely so that there can be meaningful interactions. I see this kind of thread all the time: https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&… Some part of the software changed, a user points out an inconsistency or issue that results, a CL responds, tracks the issue and talks with the PM about it as appropriate. This applies just as much to early-stage features like Flow. There are also regular "What would you like to see" kind of threads which are used for idea generation and prioritization. Not really. If you take MediaViewer, here are some of the things that changed in addition to the pace of deployment: - clearly established opt-in phase via Beta Features (which was created post-VE as a way to advertise new features) - built-in clicktracking and performance metrics from fairly early on - built-in user surveys - iterative, frequent testing of design prototypes - community liaison support from the beginning of development, working in partnership with the PM That's not to say that there isn't plenty of room for improvement, including but not limited to: - stronger success/failure metrics for any new feature - truly continuous qualitative and quantitative validation throughout the development lifecycle - staged rollouts for large wikis (%-of-audience based or otherwise) - improved microsurvey system consistently used for measuring user satisfaction I don't think we'll ever get to a place whether we'll always have consensus about whether a feature should exist, but it should be possible to get closer to consensus about how to measure whether it does what it was built to do. Not at all. The summary view you get in MV is just that: a summary. As you know, robust metadata support for Wikimedia Commons and locally hosted files is on the joint roadmap between the multimedia and Wikidata teams. MV is first and foremost what it says on the tin: a media viewer. It gives you access to the image in a form nicely sized for your browser window, without leaving the page you're on, and pre-loads next/previous images for quicker access. Whether it should show advanced metadata at all or just refer back to the File: page is debatable. Indeed, we're currently planning to user-test prototypes with readers that eliminate the metadata panel except for extended captions and which have a much more prominent "Details" link to the File: page. Early responses from community members we've spoken to about this have also been positive. This would alleviate issues with perceived munging of important templates/bits of data by more clearly giving each feature (File: page, lightbox) its purpose - we can then revisit advanced metadata integration later. We're not committing to that path yet, but we're exploring it as part of normal iterative improvement of the feature. Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

Hi Quim, Thanks for the invitation. I did not attend Wikimania but would be interested in setting up an office hour to discuss ideas about improving features design and development, including TechCom and the roles of tech ambassadors, ECT, and ECL in features. Could we set up a time off-list? Pine On Aug 8, 2014 1:10 AM, "Quim Gil" &lt;qgil(a)wikimedia.org&gt; wrote:

It's not in exactly the same place it was before, but I'm not sure I'd call it not prominent - the existing tabs have just been moved under the headline title, and then an additional [edit] button on every section heading as usual: ---- Temperate climate Read Edit 1 Discussions Updated 16 days ago More ---- Andrew. On 9 August 2014 11:57, svetlana &lt;svetlana(a)fastmail.com.au&gt; wrote: -- - Andrew Gray andrew.gray(a)dunelm.org.uk