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