Hi all.
WMF Engineering is currently composed of individual teams as documented at https://www.mediawiki.org/wiki/Wikimedia_Engineering . These teams look after the software that faces us everyday, and often work together.
Could we please have some more people (potentially a dedicated ‘community’ team) who could do these things: - encourage feedback by absolutely /anyone/ about the next features they'd like, - run programming and documentation activities requested (or started) by community [there would be a lot of small projects, unlike the big ones the current Teams are working on], - encourage localising documentation for, and centralising the location of, all community-developed programming work, - raise awareness of community development efforts across all Wikimedia projects, - actively encourage members of community become MediaWiki and Gadgets hackers in the Free Software philosophy?
This would be, in my view, a relatively small, collaboration-type team (with just half a handful of people for timezone coverage for IRC support).
Open to brainstorming and suggestions. I would compile thoughts into a wiki page afterwards to continue thinking on the idea.
Regards Gryllida.
On 5 August 2014 11:33, Gryllida gryllida@fastmail.fm wrote:
Hi all.
WMF Engineering is currently composed of individual teams as documented at https://www.mediawiki.org/wiki/Wikimedia_Engineering . These teams look after the software that faces us everyday, and often work together.
Could we please have some more people (potentially a dedicated ‘community’ team) who could do these things:
- encourage feedback by absolutely /anyone/ about the next features they'd like,
- run programming and documentation activities requested (or started) by community [there would be a lot of small projects, unlike the big ones the current Teams are working on],
- encourage localising documentation for, and centralising the location of, all community-developed programming work,
- raise awareness of community development efforts across all Wikimedia projects,
- actively encourage members of community become MediaWiki and Gadgets hackers in the Free Software philosophy?
This would be, in my view, a relatively small, collaboration-type team (with just half a handful of people for timezone coverage for IRC support).
Open to brainstorming and suggestions. I would compile thoughts into a wiki page afterwards to continue thinking on the idea.
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_Coord... * 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
On Tue, 5 Aug 2014, at 20:48, Fæ wrote:
On 5 August 2014 11:33, Gryllida gryllida@fastmail.fm wrote:
Hi all.
WMF Engineering is currently composed of individual teams as documented at https://www.mediawiki.org/wiki/Wikimedia_Engineering . These teams look after the software that faces us everyday, and often work together.
Could we please have some more people (potentially a dedicated ‘community’ team) who could do these things:
- encourage feedback by absolutely /anyone/ about the next features they'd like,
- run programming and documentation activities requested (or started) by community [there would be a lot of small projects, unlike the big ones the current Teams are working on],
- encourage localising documentation for, and centralising the location of, all community-developed programming work,
- raise awareness of community development efforts across all Wikimedia projects,
- actively encourage members of community become MediaWiki and Gadgets hackers in the Free Software philosophy?
This would be, in my view, a relatively small, collaboration-type team (with just half a handful of people for timezone coverage for IRC support).
Open to brainstorming and suggestions. I would compile thoughts into a wiki page afterwards to continue thinking on the idea.
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_Coord...
- 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
"Both please"? [This is a question! This is a brainstorming thread.]
Some part of such group of people could be paid (like the job openings you linked), and a very vast part could be volunteer and supported by the said employees (and documentation).
Gryllida.
On 5 August 2014 12:05, Gryllida gryllida@fastmail.fm wrote:
On Tue, 5 Aug 2014, at 20:48, Fæ wrote:
On 5 August 2014 11:33, Gryllida gryllida@fastmail.fm wrote:
Hi all.
WMF Engineering is currently composed of individual teams as
documented at https://www.mediawiki.org/wiki/Wikimedia_Engineering . These teams look after the software that faces us everyday, and often work together.
Could we please have some more people (potentially a dedicated
‘community’ team) who could do these things:
- encourage feedback by absolutely /anyone/ about the next features
they'd like,
- run programming and documentation activities requested (or started)
by community [there would be a lot of small projects, unlike the big ones the current Teams are working on],
- encourage localising documentation for, and centralising the
location of, all community-developed programming work,
- raise awareness of community development efforts across all
Wikimedia projects,
- actively encourage members of community become MediaWiki and Gadgets
hackers in the Free Software philosophy?
This would be, in my view, a relatively small, collaboration-type team
(with just half a handful of people for timezone coverage for IRC support).
Open to brainstorming and suggestions. I would compile thoughts into a
wiki page afterwards to continue thinking on the idea.
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_Coord...
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
"Both please"? [This is a question! This is a brainstorming thread.]
Some part of such group of people could be paid (like the job openings you linked), and a very vast part could be volunteer and supported by the said employees (and documentation).
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
Fæ wrote:
On 5 August 2014 11:33, Gryllida gryllida@fastmail.fm wrote:
WMF Engineering is currently composed of individual teams as documented at https://www.mediawiki.org/wiki/Wikimedia_Engineering . These teams look after the software that faces us everyday, and often work together.
Could we please have some more people (potentially a dedicated ‘community’ team) who could do these things:
- encourage feedback by absolutely /anyone/ about the next features
they'd like,
- run programming and documentation activities requested (or started)
by community [there would be a lot of small projects, unlike the big ones the current Teams are working on],
- encourage localising documentation for, and centralising the location
of, all community-developed programming work,
- raise awareness of community development efforts across all Wikimedia
projects,
- actively encourage members of community become MediaWiki and Gadgets
hackers in the Free Software philosophy?
This would be, in my view, a relatively small, collaboration-type team (with just half a handful of people for timezone coverage for IRC support).
Open to brainstorming and suggestions. I would compile thoughts into a wiki page afterwards to continue thinking on the idea.
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.
Theoretical overlap, perhaps. People in the role of "Community Liaison, Product Development and Strategic Change Management", a title Orwell would be proud of, are not doing what's being described in this e-mail. The current community liaisons are really paid advocates and they're tasked with shilling bad products. This isn't the fault of the people in these roles, many of whom I know and respect, but we should be honest that their role is much closer to that of a marketer or public relations person.
Substantive, meaningful communication between the people building software and the people using software is the goal, but the current implementation dramatically fails, as a number of software projects from the past two years have demonstrated and continue to demonstrate.
And of course there are separate "community advocacy" and "engineering community" teams. The Wikimedia Foundation staff is heavily bloated and I very much doubt that hiring additional staff will improve matters.
Gryllida's proposal has merit, but implementing it probably requires more than a small team. Part of the issue is that thousands of editors' views are discounted in favor of the latest hare-brained ideas from Wikimedia Foundation middle management. And while many of these ideas can be, and eventually are, killed or mitigated, it's draining work that's likely more easily accomplished with a larger pool of focused energy.
MZMcBride
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@mzmcbride.com wrote:
Fæ wrote:
On 5 August 2014 11:33, Gryllida gryllida@fastmail.fm wrote:
WMF Engineering is currently composed of individual teams as documented at https://www.mediawiki.org/wiki/Wikimedia_Engineering . These teams look after the software that faces us everyday, and often work together.
Could we please have some more people (potentially a dedicated ‘community’ team) who could do these things:
- encourage feedback by absolutely /anyone/ about the next features
they'd like,
- run programming and documentation activities requested (or started)
by community [there would be a lot of small projects, unlike the big ones the current Teams are working on],
- encourage localising documentation for, and centralising the location
of, all community-developed programming work,
- raise awareness of community development efforts across all Wikimedia
projects,
- actively encourage members of community become MediaWiki and Gadgets
hackers in the Free Software philosophy?
This would be, in my view, a relatively small, collaboration-type team (with just half a handful of people for timezone coverage for IRC support).
Open to brainstorming and suggestions. I would compile thoughts into a wiki page afterwards to continue thinking on the idea.
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.
Theoretical overlap, perhaps. People in the role of "Community Liaison, Product Development and Strategic Change Management", a title Orwell would be proud of, are not doing what's being described in this e-mail. The current community liaisons are really paid advocates and they're tasked with shilling bad products. This isn't the fault of the people in these roles, many of whom I know and respect, but we should be honest that their role is much closer to that of a marketer or public relations person.
Substantive, meaningful communication between the people building software and the people using software is the goal, but the current implementation dramatically fails, as a number of software projects from the past two years have demonstrated and continue to demonstrate.
And of course there are separate "community advocacy" and "engineering community" teams. The Wikimedia Foundation staff is heavily bloated and I very much doubt that hiring additional staff will improve matters.
Gryllida's proposal has merit, but implementing it probably requires more than a small team. Part of the issue is that thousands of editors' views are discounted in favor of the latest hare-brained ideas from Wikimedia Foundation middle management. And while many of these ideas can be, and eventually are, killed or mitigated, it's draining work that's likely more easily accomplished with a larger pool of focused energy.
MZMcBride
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Tue, Aug 5, 2014 at 7:09 PM, Pine W wiki.pine@gmail.com wrote:
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.
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.)
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#Sugge...
Pine
On Tue, Aug 5, 2014 at 10:52 PM, Steven Walling steven.walling@gmail.com wrote:
On Tue, Aug 5, 2014 at 7:09 PM, Pine W wiki.pine@gmail.com wrote:
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.
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.) _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Wed, Aug 6, 2014 at 7:06 AM, Pine W wiki.pine@gmail.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.
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.
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@gmail.com wrote:
On Wed, Aug 6, 2014 at 7:06 AM, Pine W wiki.pine@gmail.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.
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. _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Tue, Aug 5, 2014 at 1:53 PM, MZMcBride z@mzmcbride.com wrote:
Theoretical overlap, perhaps. People in the role of "Community Liaison, Product Development and Strategic Change Management", a title Orwell would be proud of, are not doing what's being described in this e-mail. The current community liaisons are really paid advocates and they're tasked with shilling bad products. This isn't the fault of the people in these roles, many of whom I know and respect, but we should be honest that their role is much closer to that of a marketer or public relations person.
You're being a jerk in this paragraph, Max. There is a huge difference in attitude, skills, and experience between marketers/PR people and the Wikimedians that work in the community liason role. The community liasons put in a lot of blood, sweat, and tears to advocate not only *to *the community, but *for it* within the Foundation. They do this quietly, often behind the scenes, and with little praise. If you know and respect these people, the respectful thing would not be to reduce their very hard jobs to a pithy but inaccurate summary for your rhetorical purposes.
To come back to the proposal: there's a lot of merit to the idea of a formal community group not paid by the WMF to get deeply involved in understanding the engineering roadmap and advising the Foundation. The list of potential tasks Gryllida made is pretty good.
There are certainly staffers who've seriously considered trying to set this up. The only barrier has been time and energy. It's probably best if the community just goes ahead and elects a volunteer group, and then proposes that it work with WMF engineering and product teams. TL;DR: be bold. If you're not proposing setting up something involving money, the only barrier is finding the right people, which will just take time. A gesture of good faith might be to involve one relevant WMF person, like Rachel diCerbo (the new director of the community liasons in product). She's been doing this kind of thing a long time.
Steven
On Wed, 6 Aug 2014, at 15:44, Steven Walling wrote:
The community liasons put in a lot of blood, sweat, and tears to advocate not only *to *the community, but *for it* within the Foundation.
This activity should be redundant. If someone in the Foundation fails to see the community, it should be fixed.
Steven Walling wrote:
On Tue, Aug 5, 2014 at 1:53 PM, MZMcBride z@mzmcbride.com wrote:
Theoretical overlap, perhaps. People in the role of "Community Liaison, Product Development and Strategic Change Management", a title Orwell would be proud of, are not doing what's being described in this e-mail. The current community liaisons are really paid advocates and they're tasked with shilling bad products. This isn't the fault of the people in these roles, many of whom I know and respect, but we should be honest that their role is much closer to that of a marketer or public relations person.
You're being a jerk in this paragraph, Max. There is a huge difference in attitude, skills, and experience between marketers/PR people and the Wikimedians that work in the community liason role. The community liasons put in a lot of blood, sweat, and tears to advocate not only *to *the community, but *for it* within the Foundation. They do this quietly, often behind the scenes, and with little praise. If you know and respect these people, the respectful thing would not be to reduce their very hard jobs to a pithy but inaccurate summary for your rhetorical purposes.
Blood, sweat, and tears? A very hard job? I'm not sure we're talking about the same thing. Being an emergency room doctor, for example, is a very hard job that involves blood, sweat, and tears. What you're describing doesn't seem to match reality. Some might even describe it as rhetoric.
I'll stand by what I said previously. The community liaisons (two Is) are currently in the role of trying to sell the community on bad software. Good software, surprisingly, doesn't need hired "community liaisons" to roam around the large wikis to explain and defend its virtues. If you want to respond to the substantive point, please do. Otherwise, I don't really think it's fair nor productive to simply make appeals to emotion.
MZMcBride
On 7 August 2014 00:56, MZMcBride z@mzmcbride.com wrote:
I'll stand by what I said previously. The community liaisons (two Is) are currently in the role of trying to sell the community on bad software. Good software, surprisingly, doesn't need hired "community liaisons" to roam around the large wikis to explain and defend its virtues. If you want to respond to the substantive point, please do. Otherwise, I don't really think it's fair nor productive to simply make appeals to emotion.
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.
On 8 August 2014 01:29, geni geniice@gmail.com wrote:
On 7 August 2014 00:56, MZMcBride z@mzmcbride.com wrote:
I'll stand by what I said previously. The community liaisons (two Is) are currently in the role of trying to sell the community on bad software. Good software, surprisingly, doesn't need hired "community liaisons" to roam around the large wikis to explain and defend its virtues. If you want to respond to the substantive point, please do. Otherwise, I don't really think it's fair nor productive to simply make appeals to emotion.
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.
Unfortunately - and we quite definitely saw this in the VE introduction - it leaves a lot of them in the position of customer service ablative firewall, the designated targets of people's frustration.
- d.
David Gerard wrote:
Unfortunately - and we quite definitely saw this in the VE introduction - it leaves a lot of them in the position of customer service ablative firewall, the designated targets of people's frustration.
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
Quoting MZMcBride: "...the two issues (a rush to deploy features versus resource allocation for unwanted features), while sometimes intertwined, can certainly also be discrete." I agree with you in this point, and the Technical Committee is intended in part to improve both situations.
Quoting David: "Unfortunately - and we quite definitely saw this in the VE introduction - it leaves a lot of them in the position of customer service ablative firewall, the designated targets of people's frustration." Yes, and this is unfortunate. I sometimes feel that the Community Advocacy and Engineering Community Liaison groups get blame for decisions that were made by other people, and these liaisons are placed in the difficult position of trying to please everyone. I have sympathy for the people in those roles and I feel that they often do good work for the WMF and the community.
Quim, it seems to me that the methods used by Features have repeatedly produced troubled results over the years, so it's time for a different approach. Grantmaking has a community-intensive approach to making major decisions and I think the same approach should be taken in Features. I am optimistic that embedding the community deeply in leading Features would be a long-term change for the better. I believe that the Tech Ambassadors aren't empowered to make high-level community recommendations about Features as the Technical Committee is intended to do, although Tech Ambassadors may want to volunteer to serve on the Technical Committee and/or be integrated into its work. I would like to invite you and the Tech Ambassadors to participate in the discussion about the Technical Committee on the Board Noticeboard [1].
Pine
On Fri, Aug 8, 2014 at 8:34 AM, Pine W wiki.pine@gmail.com wrote:
Quim, it seems to me that the methods used by Features have repeatedly produced troubled results over the years, so it's time for a different approach.
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".
Grantmaking has a community-intensive approach to making major decisions and I think the same approach should be taken in Features. I am optimistic that embedding the community deeply in leading Features would be a long-term change for the better. I believe that the Tech Ambassadors aren't empowered to make high-level community recommendations about Features as the Technical Committee is intended to do, although Tech Ambassadors may want to volunteer to serve on the Technical Committee and/or be integrated into its work. I would like to invite you and the Tech Ambassadors to participate in the discussion about the Technical Committee on the Board Noticeboard [1].
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().
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" qgil@wikimedia.org wrote:
On Fri, Aug 8, 2014 at 8:34 AM, Pine W wiki.pine@gmail.com wrote:
Quim, it seems to me that the methods used by Features have repeatedly produced troubled results over the years, so it's time for a different approach.
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".
Grantmaking has a community-intensive approach to making major decisions and I think the same approach should be taken in Features. I am optimistic that embedding the community deeply in leading Features would be a long-term change for the better. I believe
that
the Tech Ambassadors aren't empowered to make high-level community recommendations about Features as the Technical Committee is intended to do, although Tech Ambassadors may want to volunteer to serve on the Technical Committee and/or be integrated into its work. I would like to invite you and the Tech Ambassadors to participate in the discussion about the Technical Committee on the Board Noticeboard [1].
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(). _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Fri, Aug 8, 2014 at 2:47 AM, MZMcBride z@mzmcbride.com 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."
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&a...
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.
But the Wikimedia Foundation took the lesson to be that it simply needed to move a bit more slowly, not more smartly.
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.
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.
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
On Fri, 8 Aug 2014, at 11:47, MZMcBride wrote:
[...] 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!). [...] MZMcBride
Related: http://unicorn.wmflabs.org/winter/index.html?page=Temperate_climate This re-make of the Vector skin lacks a prominent Edit button. I would adore talking to the relevant project people, but I /do not see them/ on this wonderful page: https://www.mediawiki.org/wiki/Winter
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@fastmail.com.au wrote:
On Fri, 8 Aug 2014, at 11:47, MZMcBride wrote:
[...] 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!). [...] MZMcBride
Related: http://unicorn.wmflabs.org/winter/index.html?page=Temperate_climate This re-make of the Vector skin lacks a prominent Edit button. I would adore talking to the relevant project people, but I /do not see them/ on this wonderful page: https://www.mediawiki.org/wiki/Winter
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Hi Gryllida,
On Tue, Aug 5, 2014 at 12:33 PM, Gryllida gryllida@fastmail.fm wrote:
Could we please have some more people (potentially a dedicated ‘community’ team) who could do these things:
The tasks you describe would or could fall into the responsibilities of two teams at the WMF:
https://www.mediawiki.org/wiki/Community_Engagement_(Product) https://www.mediawiki.org/wiki/Engineering_Community_Team
Also the own development teams (including product managers) are involved in some of these activities, as part of their development and deployment process.
- encourage feedback by absolutely /anyone/ about the next features they'd
like,
Betas and Bugzilla today. Phabricator should make it easier to provide feedback in a wider range of topics, not only "bugs".
- run programming and documentation activities requested (or started) by
community [there would be a lot of small projects, unlike the big ones the current Teams are working on],
I for one would welcome more initiatives and requests from the community. The PyWikiBot is a good example of a team that asks us to help organizing and promoting their special activities. More proposals are welcome.
- encourage localising documentation for, and centralising the location
of, all community-developed programming work,
Nemo has been a very active advocate, and I want to believe that WMF teams have been increasingly relying on centralized and translatable documentation in their releases, asking explicitly for translation help.
- raise awareness of community development efforts across all Wikimedia
projects,
This is an explicit goal for Tech Ambassadors and Community Liaisons.
- actively encourage members of community become MediaWiki and Gadgets
hackers in the Free Software philosophy?
Ah, you are touching a point of my personal ToDo list that I know we are not addressing as well as we could. Still, we are trying to focus this line of activity in conjunction with our participation in Google Summer of Code, FOSS Outreach Program for Women, and recently also Google Code-in and Facebook Open Academy.
This would be, in my view, a relatively small, collaboration-type team
(with just half a handful of people for timezone coverage for IRC support).
To me this is not a task of one team or two, but a set of practices better embodies in our development and deployment processes, and also a set of activities that a larger community should embrace.
In fact, this is what my Wikimania session is about! Shameless plug:
https://wikimania2014.wikimedia.org/wiki/Submissions/The_Wikimedia_open_sour...
(It was scheduled at the "Technology, Interface & Infrastructure" track but believe me, it's more about WikiCulture & Community.)
I'm curious about the subject of you message, especially the "let's elect people" part. What do you mean?
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:
- encourage feedback by absolutely /anyone/ about the next features they'd
like,
Betas and Bugzilla today. Phabricator should make it easier to provide feedback in a wider range of topics, not only "bugs".
99% of users of Wikimedia projects don't /know/ about these tools. That's the problem, and your response is not reflecting it.
- run programming and documentation activities requested (or started) by
community [there would be a lot of small projects, unlike the big ones the current Teams are working on],
I for one would welcome more initiatives and requests from the community. The PyWikiBot is a good example of a team that asks us to help organizing and promoting their special activities. More proposals are welcome.
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.
- encourage localising documentation for, and centralising the location
of, all community-developed programming work,
Nemo has been a very active advocate, and I want to believe that WMF teams have been increasingly relying on centralized and translatable documentation in their releases, asking explicitly for translation help.
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.
- raise awareness of community development efforts across all Wikimedia
projects,
This is an explicit goal for Tech Ambassadors and Community Liaisons.
Related message: http://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073696.html
- actively encourage members of community become MediaWiki and Gadgets
hackers in the Free Software philosophy?
Ah, you are touching a point of my personal ToDo list that I know we are not addressing as well as we could.
That is correct, and is the problem.
Still, we are trying to focus this line of activity in conjunction with our participation in Google Summer of Code, FOSS Outreach Program for Women, and recently also Google Code-in and Facebook Open Academy.
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?"
This would be, in my view, a relatively small, collaboration-type team
(with just half a handful of people for timezone coverage for IRC support).
To me this is not a task of one team or two, but a set of practices better embodies in our development and deployment processes, and also a set of activities that a larger community should embrace.
In fact, this is what my Wikimania session is about! Shameless plug:
https://wikimania2014.wikimedia.org/wiki/Submissions/The_Wikimedia_open_sour...
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.
(It was scheduled at the "Technology, Interface & Infrastructure" track but believe me, it's more about WikiCulture & Community.)
I'm curious about the subject of you message, especially the "let's elect people" part. What do you mean?
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.
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@fastmail.com.au wrote:
On Wed, 6 Aug 2014, at 06:58, Quim Gil wrote:
- encourage feedback by absolutely /anyone/ about the next features
they'd
like,
Betas and Bugzilla today. Phabricator should make it easier to provide feedback in a wider range of topics, not only "bugs".
99% of users of Wikimedia projects don't /know/ about these tools. That's the problem, and your response is not reflecting it.
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_outrea... https://www.mediawiki.org/wiki/Project_talk:New_contributors#English_Wikiped...
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.
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@wikimedia.org wrote:
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@fastmail.com.au wrote:
On Wed, 6 Aug 2014, at 06:58, Quim Gil wrote:
- encourage feedback by absolutely /anyone/ about the next features
they'd
like,
Betas and Bugzilla today. Phabricator should make it easier to provide feedback in a wider range of topics, not only "bugs".
99% of users of Wikimedia projects don't /know/ about these tools. That's the problem, and your response is not reflecting it.
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_outrea...
https://www.mediawiki.org/wiki/Project_talk:New_contributors#English_Wikiped...
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. _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
About https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_noticeboard#Sugge...
On Thu, Aug 7, 2014 at 10:52 AM, Pine W wiki.pine@gmail.com wrote:
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.
This is just my personal opinion. Sitting here every day, and seeing also not only the big hot topics but the many small novelties and discussions that the tech community generates, the Tech Ambassadors are the ones actually doing something in order to keep a fluent communication between developers and editors today. I would encourage and empower them to try out solutions to get the communities better involved as participants of our development process.
I would trust a process promoted by the Tech Ambassadors and evolved through many iterations and lessons learned, more than a committee that went from community proposal to board approval in one go. I don't think the problems we have will be solved by a committee of members elected or appointed for periods of n years. I would rather see how certain ambassadors earn the respect of their content projects and the technical community (WMF teams included) through continuous participation, wise words, and useful work.
Yes, we need some structure, but a light and flexible structure that fits in our open source development process.
On Thu, Aug 7, 2014 at 3:33 AM, Quim Gil qgil@wikimedia.org wrote:
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?
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
wikimedia-l@lists.wikimedia.org