[Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[Gryllida]

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.

___
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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[Fæ]

On 5 August 2014 11:33, Gryllida  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_Coordinator
* 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
-- 
fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae

___
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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[Gryllida]

On Tue, 5 Aug 2014, at 20:48, Fæ wrote:
> On 5 August 2014 11:33, Gryllida  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_Coordinator
> * 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.

___
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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[Risker]

On 5 August 2014 12:05, Gryllida  wrote:

> On Tue, 5 Aug 2014, at 20:48, Fæ wrote:
> > On 5 August 2014 11:33, Gryllida  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_Coordinator
> > * 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).
>
>

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
___
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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[MZMcBride]

Fæ wrote:
>On 5 August 2014 11:33, Gryllida  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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[Pine W]

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"  wrote:

> Fæ wrote:
> >On 5 August 2014 11:33, Gryllida  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,
> 
___
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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[Quim Gil]

Hi Gryllida,

On Tue, Aug 5, 2014 at 12:33 PM, Gryllida  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_source_project_and_you

(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?
___
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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[svetlana]

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_source_project_and_you

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.

___
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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[Steven Walling]

On Tue, Aug 5, 2014 at 1:53 PM, MZMcBride  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
___
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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[Steven Walling]

On Tue, Aug 5, 2014 at 7:09 PM, Pine W  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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[Pine W]

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#Suggestion_for_the_Board:_Technology_Committee

Pine






On Tue, Aug 5, 2014 at 10:52 PM, Steven Walling 
wrote:

> On Tue, Aug 5, 2014 at 7:09 PM, Pine W  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,
> 
>
___
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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[Steven Walling]

On Wed, Aug 6, 2014 at 7:06 AM, Pine W  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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[Pine W]

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 
wrote:

> On Wed, Aug 6, 2014 at 7:06 AM, Pine W  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,
> 
>
___
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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[svetlana]

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.

___
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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[MZMcBride]

Steven Walling wrote:
>On Tue, Aug 5, 2014 at 1:53 PM, MZMcBride  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



___
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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[Quim Gil]

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  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_outreach.jpg
https://www.mediawiki.org/wiki/Project_talk:New_contributors#English_Wikipedia_first_26213

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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[Pine W]

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"  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  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_outreach.jpg
>
> https://www.mediawiki.org/wiki/Project_talk:New_contributors#English_Wikipedia_first_26213
>
> 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,
> 
___
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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[pi zero]

On Thu, Aug 7, 2014 at 3:33 AM, Quim Gil  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  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 .

Pi zero
___
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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[Quim Gil]

About
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_noticeboard#Suggestion_for_the_Board:_Technology_Committee

On Thu, Aug 7, 2014 at 10:52 AM, Pine W  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.
___
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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[geni]

On 7 August 2014 00:56, MZMcBride  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.


-- 
geni
___
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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[David Gerard]

On 8 August 2014 01:29, geni  wrote:
> On 7 August 2014 00:56, MZMcBride  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.

___
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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[MZMcBride]

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



___
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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[Pine W]

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

[1] https://meta.wikimedia.org/wiki/Board_noticeboard
___
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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[Erik Moeller]

On Fri, Aug 8, 2014 at 2:47 AM, MZMcBride  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&diff=619977472&oldid=619888941

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
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

___
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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[Quim Gil]

On Fri, Aug 8, 2014 at 8:34 AM, Pine W  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, 

Re: [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[Pine W]

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"  wrote:

> On Fri, Aug 8, 2014 at 8:34 AM, Pine W  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,
> 
___
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,