On Fri, Jun 11, 2010 at 2:25 PM, wrote:
> Chad, I'm hesitant to reply to your note, because I feel like "defending the
> staff against the community" is a bad role for me: it tends to polarize and
> divide, rather than helping us all work together well. And I think I do, for
> the most part,
On Fri, Jun 11, 2010 at 8:22 AM, Michael Snow wrote:
> Chad wrote:
>> On Fri, Jun 11, 2010 at 2:49 AM, Michael Snow wrote:
>>
>>> ...if for example I was qualified to review a
>>> staff member's patch (which I'm not), I might want to think twice about
>>> what audience gets that feedback.
>>>
>>>
s would be good for everyone. I realize
that not everyone needs that, and it's obvious that not everyone will get it,
whether they need it or not. But I think it's a worthy goal :-)
Thanks,
Sue
-Original Message-
From: Chad
Date: Fri, 11 Jun 2010 07:13:37
To: Wikimedia F
Aryeh Gregor wrote:
> On Fri, Jun 11, 2010 at 11:22 AM, Michael Snow wrote:
>
>> The replies to my comment are missing the point. Sure, the developers
>> themselves need to be able to handle public criticism of their work,
>> just like wiki editors. But I was responding to Austin's comment in
>
On Fri, Jun 11, 2010 at 11:22 AM, Michael Snow wrote:
> The replies to my comment are missing the point. Sure, the developers
> themselves need to be able to handle public criticism of their work,
> just like wiki editors. But I was responding to Austin's comment in
> particular about board member
Chad wrote:
> On Fri, Jun 11, 2010 at 2:49 AM, Michael Snow wrote:
>
>> ...if for example I was qualified to review a
>> staff member's patch (which I'm not), I might want to think twice about
>> what audience gets that feedback.
>>
>> --Michael Snow
>>
> Why? If they're contributing a pat
On Fri, Jun 11, 2010 at 2:49 AM, Michael Snow wrote:
> ...if for example I was qualified to review a
> staff member's patch (which I'm not), I might want to think twice about
> what audience gets that feedback.
>
> --Michael Snow
>
Why? If they're contributing a patch to MediaWiki, they should go
On Fri, Jun 11, 2010 at 4:49 PM, Michael Snow wrote:
> ... if for example I was qualified to review a
> staff member's patch (which I'm not), I might want to think twice about
> what audience gets that feedback.
Ugh.
You are implicitly expecting that the patch submitter and the code
reviewer are
On 6/9/2010 2:01 AM, Austin Hair wrote:
> On Wed, Jun 9, 2010 at 12:55 AM, Aryeh Gregor
> wrote:
>
>> 2) Make sure that every paid developer spends time dealing with the
>> community. This can include giving support to end users, discussing
>> things with volunteers, reviewing patches, etc.
On Wed, Jun 9, 2010 at 8:46 PM, Rob Lanphier wrote:
> As you know, any time you want to compel someone to do something, there's
> always the carrot and the stick. One thing I don't like about the way
> you've phrased that is that is that you seem to be advocating the stick. Am
> I reading that r
On Fri, Jun 11, 2010 at 7:00 AM, Aryeh Gregor
wrote:
>
>
> Is vendor-to-customer development more efficient than peer-to-peer in
> the end? A lot of open-source projects (e.g., Firefox) have as many
> features as their closed-source counterparts, on a much smaller
> budget.
> ...
>... Empiri
On Thu, Jun 10, 2010 at 8:59 AM, Birgitte SB wrote:
> --- On Wed, 6/9/10, Rob Lanphier wrote:
> > From the vantage point of the "vendor" in this case, the
> > problem is compounded by the cognitive bias Erik pointed to (belief
> > that the group you're a member of is diverse, whereas other group
--- On Wed, 6/9/10, Rob Lanphier wrote:
>
> One undertone that I've witnessed everywhere is that people
> in open source
> communities that have a clear organizational "owner" is
> that there is a very
> uneven distribution of people who want a peer-to-peer
> relationship versus a
> customer-
On Wed, Jun 9, 2010 at 7:08 PM, MZMcBride wrote:
> Rob Lanphier wrote:
> > So, I'll start chipping in my work at the page Erik has started:
> > http://usability.wikimedia.org/wiki/Product_Development_Process_Ideas
>
> You all really just don't get it, do you? Part of the problem is that the
> usa
Rob Lanphier wrote:
> So, I'll start chipping in my work at the page Erik has started:
> http://usability.wikimedia.org/wiki/Product_Development_Process_Ideas
You all really just don't get it, do you? Part of the problem is that the
usability wiki is viewed as a walled garden. Your "solution" is t
On Tue, Jun 8, 2010 at 6:28 PM, Aryeh Gregor
> wrote:
> It's not specific to Wikimedia, it's practically universal in
> open-source development. To get it to happen, you need pushing from
> the top: formally stating it as part of people's job duties (so they
> don't feel they have to do "real wo
IBMs decision to get rid of all internal communication sounds to me as a
very good practice for us.
It also fits in well with the wikipedia culture of consensus in decision
making.
Following this comm. strategy involves the large volunteer community, and
taps on the vast knowledge of our community
On Tue, Jun 8, 2010 at 9:28 PM, Aryeh Gregor
wrote:
> It's not specific to Wikimedia, it's practically universal in
> open-source development. To get it to happen, you need pushing from
> the top: formally stating it as part of people's job duties (so they
> don't feel they have to do "real work"
I think the idea that Aryeh Gregor brought up is incredible. We should
follow the strategy use by IBM in helping develop Linux. Open all
discussion to the Wikimedia community will bring the power of Wikipedia's
collaborative process to the operations of of Wikimedia. Volunteers would
get involve
On Wed, Jun 9, 2010 at 12:55 AM, Aryeh Gregor
wrote:
> 2) Make sure that every paid developer spends time dealing with the
> community. This can include giving support to end users, discussing
> things with volunteers, reviewing patches, etc. They should be doing
> this on paid time, and they sh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/06/2010 03:28, Aryeh Gregor wrote:
> I recall reading that IBM improved its
> participation in the Linux kernel community by getting rid of all
> internal communications among its kernel developers, meaning they had
> to use the public project l
Hoi,
The water is nice, I have tried it ..
http://prototype.wikimedia.org/en-idea/ideatorrent/
I even blogged about it ...
http://ultimategerardm.blogspot.com/2010/06/ideatorrent-for-mediawiki-ideas.html
Thanks,
GerardM
On 9 June 2010 01:28, phoebe ayers wrote:
> On Tue, Jun 8, 2010 at 3:3
On Wed, Jun 9, 2010 at 11:28 AM, Aryeh Gregor
wrote:
> ...
> It's also worth pointing out that a good way *not* to engage with the
> community is to not touch preexisting code that volunteers are
> familiar with. All the Usability Initiative stuff was created
> separately: a new skin, and all oth
On Tue, Jun 8, 2010 at 8:48 PM, Benjamin Lees wrote:
> I really agree with this sentiment, but it seems difficult to get staff to
> really be part of the community unless they're _from_ the community. The
> developers I've seen discuss their personal opinions on public fora
> (especially in ways
On Tue, Jun 8, 2010 at 6:55 PM, Aryeh Gregor
> wrote:
> 2) Make sure that every paid developer spends time dealing with the
> community. This can include giving support to end users, discussing
> things with volunteers, reviewing patches, etc. They should be doing
> this on paid time, and they
On Tue, Jun 8, 2010 at 4:28 PM, phoebe ayers wrote:
> On Tue, Jun 8, 2010 at 3:31 PM, Erik Moeller wrote:
>> 7) Further experimentation with tools like IdeaTorrent for large-scale
>> brainstorming and ranking purposes (we have a prototype running at
>> http://prototype.wikimedia.org/en-idea/ideat
On Tue, Jun 8, 2010 at 3:31 PM, Erik Moeller wrote:
> 7) Further experimentation with tools like IdeaTorrent for large-scale
> brainstorming and ranking purposes (we have a prototype running at
> http://prototype.wikimedia.org/en-idea/ideatorrent/ ).
I was super excited to see this go up the o
> The basic attitude has to be that paid developers are treated
> identically to volunteers, except that you can tell the former what to
> do and expect them to put in more time. There should not be
> communication between paid developers and the community, paid
> developers should be an integral
On Tue, Jun 8, 2010 at 6:31 PM, Erik Moeller wrote:
> With all this in mind, here are just a few concrete ideas for closing the gap:
>
> 1) Embedding teams funded by WMF into larger, publicly visible
> workgroups which include volunteers and which meet regularly e.g. via
> IRC;
> 1 a) Outreach to
Hoi,
As you may know, I had reservations about the fact that the UX was funded
for the English language Wikipedia only. This turned out well; there was
attention for right to left languages, testing environments for several
languages were created. In the tools there was time to include character
se
Hello all,
the massive thread regarding the default sidebar language link
expansion state has surfaced a number of fundamental and significant
questions regarding the working relationship between the Wikimedia
Foundation and the larger Wikimedia volunteer community. This message
represents my snap
31 matches
Mail list logo
