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:

Hm. Garfield is the closest person I know in the Foundation to the FDC in its role of evaluating the Foundation's Annual Plan for the entire organization. The only other people I can think of who might be able to comment for the whole org are Gayle and Lila. By the way, after the latest Product launch controversy (MediaViewer) I proposed the creation of a Board-chartered Technology Committee that would include significant community involvement. See https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_noticeboard#Sugg… Pine On Tue, Aug 5, 2014 at 10:52 PM, Steven Walling <steven.walling(a)gmail.com> wrote:

I was asking for an overview of what WMF as a whole is doing in response to the feedback on the Annual Plan, including FDC feedback, about performance metrics such as a call for more SMART goals. Pine On Tue, Aug 5, 2014 at 11:22 PM, Steven Walling <steven.walling(a)gmail.com> wrote:

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.

On 7 August 2014 00:56, MZMcBride <z(a)mzmcbride.com> 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 8:34 AM, Pine W <wiki.pine(a)gmail.com> wrote: Note that the approach of empowering Tech Ambassadors to explicitly represent the voice of the content communities hasn't been tried yet. To me, this is also "a different approach". The Wikimedia Engineering Community Team can work here and now on the specific goal of "let's empower people to serve on the Wikimedia Engineering Community Team". We can work with the 'people' interested to bring them closer to the development process and tell them how to participate in it effectively. This line of work doesn't get in the way of a potential Technical Committee. I just think that if a committee like that should exist, their potential members should be active at e.g. https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals and related planning pages already today, because the possibility to ask and influence already exists. Anyway, I should have a shower and some breakfast before running to Wikimania. If you happen to be in London and you find this topic exciting, I will be very happy to share a chat with or without coldBeverage().

On Fri, Aug 8, 2014 at 2:47 AM, MZMcBride <z(a)mzmcbride.com> 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

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 <svetlana(a)fastmail.com.au> wrote: -- - Andrew Gray andrew.gray(a)dunelm.org.uk

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.

Quim, can you clarify your comments about the Technology Committee? The committee is my proposal as a community member; it is not a top-down, Board-created idea. Its membership is designed to be broadly representative of the MediaWiki user community. The Board mandate is necessary to give TechCom similar placement to AffCom, the FDC, and other community-led and Board-chartered committees that report directly to the Board. I am not sure how you see TechCom as anything but a community-based organization. Pine On Aug 7, 2014 12:33 AM, "Quim Gil" <qgil(a)wikimedia.org> wrote:

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