Similarly to what you are describing, Micru, BeWelcome has a process to
identify issues and resolve them in a community discussion. It’s a sort of
communal product specification/design.
The process looks like: 
1/ firstly, community members can submit issues or product ideas,
2/ secondly, there is a discussion with proposed resolutions,
3/ thirdly, a vote between the various proposed resolutions,
4/ lastly, the development phase itself.
Although we have some sort of such process (Idea lab, RFC, mailing lists,
bug tracker, MediaWiki.org), it’s not as easy to find where are the ideas
of products, where are the development of these ideas, and where and how
you can give your voice to influence the path of the development.
Personally I like a lot the BeWelcome process (and it’s a non-technical
member who presented me that), and I find you could reuse it in Wikimedia,
probably in a customized form, and with short and intuitive product ideas
and resolutions (avoid too long pages at first sight).
Le mardi 26 juin 2014 15:12:03 (CEST), David Cuenca a écrit :
Erik (and others), is there any coordination page where groups could
take, or discuss "requests for development" or "requests for
I saw often that sometimes the hard-to-achieve consensus is found, but
there is no way to evaluate the idea further. What now happens is:
- several development proposals materialize through different channels
(community, user groups, idea lab, RFCs, etc)
- there is a general consensus about "project A"
- limbo.... or an IEG, but as Ilario says, that doesn't guarantee its
future viability or integration with current or planned workflows, or
availability of resources for maintenance
It would be more rational to have a further step in the pipeline where
development ideas could be commented, "shot down", or "approved for
commitment" by the ones who actually can understand how they fit in the
broader product management/life-cycle context (engineering? PMs?
There are often community ideas that on first sight look great, but when
you think about the potential problems, implications, costs, or stepping
the toes of other developments, that it is more rational not to start
or delay them until certain conditions are met. But no voice is heard,
that causes frustration and a sense of disconnection in the community,
just a single statement "this shouldn't be done because X", would make
everyone more aware of the limits.
And the opposite too, when some idea gather community support and is
green-lighted for further commitment, that would make chapters or other
organizations more confident about what is wanted and how.
On Thu, Jun 26, 2014 at 5:54 AM, Erik Moeller <e...@wikimedia.org> wrote:
At the Zurich Hackathon, I met with a couple of folks from WM-CH who
were interested in talking about ways that chapters can get involved
in engineering/product development, similar to WM-DE's work on
My recommendation to them was to consider working on GLAM-related
tooling. This includes helping improve some of the reporting tools
currently running in Labs (primarily developed by the illustrious and
wonderful Magnus Manske in his spare time), but also meeting other
requirements identified by the GLAM community  and potentially
helping with the development of more complex MediaWiki-integrated
tools like the GLAMWiki-Toolset.
There's work that only WMF is well positioned to do (like feeding all
media view data into Hadoop and providing generalized reports and
APIs), but a lot of work in the aforementioned categories could be
done by any chapter and could easily be scaled up from 1 to 2 to 3
FTEs and beyond as warranted. That's because a lot of the tools are
separate from MediaWiki, so code review and integration requirements
are lower, and it's easier for technically proficient folks to help.
In short, I think this could provide a nice on-ramp for a chapter or
chapters to support the work of volunteers in the cultural sector with
appropriate technology. This availability of appropriate technology is
clearly increasingly a distinguishing factor for Wikimedia relative to
more commercial offerings in its appeal to the cultural sector.
At the same time, WMF itself doesn't currently prioritize work with
the cultural sector very highly, which I think is appropriate given
all the other problems we have to solve. So if this kind of work has
to compete for attention with much more basic improvements to say the
uploading pipeline or the editing tools, it's going to lose. Therefore
I think having a "cultural tooling" team or teams in the larger
movement would be appropriate.
I've not heard back from WM-CH yet on this, but I also don't think
it's an exclusive suggestion, so wanted to put the idea in people's
heads in case other organizations in the movement want to help with
it. I do want WMF to solve the larger infrastructure problems, but the
more specialized tooling is likely _not_ going to be high on our
agenda anytime soon.
VP of Engineering and Product Development, Wikimedia Foundation
Wikimedia-l mailing list, guidelines at:
Wikimedia-l mailing list, guidelines at: