You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@vxquery.apache.org by Marvin Humphrey <ma...@rectangular.com> on 2013/11/16 05:08:04 UTC

Transparency

Greetings, VXQuery folks,

Since volunteering as Mentor, I've been scanning through the archives of your
dev list in order to come up to speed on your project.  It's been a pleasant
read: communications are respectful, newcomers are welcomed, technical
concepts are explained cogently and patiently.  The integration of Preston
into the team has been very well done.

Nevertheless, I may have a suggestion that could help you out.  Here's a quote
from Vinayak from the release thread on general@incubator...

    http://s.apache.org/b0I

    [...] In fact a lot more work gets done on the project than what appears
    on "visible" forums like mailing lists.  We use IM and Skype much more
    than we use mailing lists.

... here's something from Till back in July on this list...

    http://s.apache.org/Xzd

    Wrt to the other points you mentioned, collaboration seems generally
    effective (albeit not always on the list), technical infrastructure is not
    a big problem, and most things I learn about ASF culture I learn from
    discussions on general@i.a.o.

... and here's another quote from Till back in January 2012:

    http://s.apache.org/oO0

    Hi Jukka,

    you are right, the consideration hasn't been happening on the list, so
    Apache-wise it didn't happen.

In that last excerpt, Till is making a reference to a popular maxim at Apache:
"If it didn't happen on the dev list, it didn't happen."  (Sometimes rendered
with minor variations such as "on a mailing list".)  Apache Board member
Bertrand Delacrataz and current Apache President Ross Gardler explain[1]:

    http://grep.codeconsult.ch/2011/08/05/how-to-fix-your-project-collaboration-model/

    In an ASF project, all decisions are made on a single developers mailing
    list.

    Backchannel discussions are inevitable: someone will meet a coworker at
    the coffee machine, people attend conferences, talk on IRC, etc. There’s
    nothing wrong with that, but the rule is that as soon as a discussion
    turns into something that has impact on the project, it must come back to
    the dev list. The goal is for all project participants to have the same
    information from a single source.

    http://osswatch.jiscinvolve.org/wp/2012/05/08/what-makes-a-community-led-project-work/

    ‘If it didn’t happen on the dev list, it didn’t happen’ – meaning no
    decision about the project can be made outside of the public development
    list. Proposals can be drawn up elsewhere, but decisions occur on the
    public list. Academic projects, like open source projects in general,
    often involve collaborators from a variety of geographic regions. This can
    make it difficult to ensure that everyone is kept informed and engaged.
    Apache projects require that all significant decisions are made in public
    so that no participant (or potential participant) is excluded from the
    process.

Small, tight-knit communities sometimes have difficulty adapting to a
development model where mailing list discussions are central.  Even when the
participants have a lot of experience collaborating in distributed
environments and are open to new ideas, it takes conscious effort:

    http://s.apache.org/vr

    Community growth is a difficult problem that is central to the Apache
    mission, and it will be an important challenge for the proposed Aurora
    podling since all the initial contributors work for the same company
    (Twitter).  It will be tempting to make architectural decisions in private
    for the sake of efficiency, but doing so will stunt the project's growth.
    It's important to hold project discussions out in the open where as
    many people as possible can witness them and potentially jump in.

Apache is a great place to get involved because our projects are not just open
source, they are open governance.  It is fundamental to our meritocratic model
that if someone makes major contributions and collaborates well, eventually
they will be given a governance stake in the form of PMC membership[2].
Together, the PMC determines the direction of the project, within the context
of the larger community.  That's not possible when crucial information is not
being made available to everyone.

So, I think there's may be an opportunity here.  VXQuery has appeared at times
to have a problem with low activity because mailing-list volume is sparse.
That can dampen enthusiasm, discouraging people from getting involved or
staying involved.  But apparently, there is more going on than meets the eye.

I did not get the impression when reading through the archives that anyone was
deliberately being secretive -- in fact, had you folks not volunteered that a
lot of private-channel discussions were happening, I might not have guessed.
How about making an effort to increase the transparency of your development
communications?  A lot of possibilities could open up.

Marvin Humphrey

[1] As supplementary material, here are a couple general@incubator discussions
    on the role of real-time communications:
    http://markmail.org/message/kt73gkrjhsczsjbo
    http://markmail.org/message/gpg67b7amoqlgeld

[2] http://www.apache.org/foundation/how-it-works.html#meritocracy

Re: Transparency

Posted by Vinayak Borkar <vi...@gmail.com>.
Marvin,


Thanks for raising this issue. Going forward, I would like to see us use 
the Apache mailing lists for most communications related to VXQuery that 
are currently using side-channels like personal emails. Moreover, I 
would suggest that any out of band communications using more transient 
channels like skype or face-to-face are at least summarized on the 
mailing list.

I will send more topic-centric emails to the dev list to initiate a 
description/discussion about some of the ongoing work on the project 
that has not yet been talked about on the list.

Thanks,
Vinayak



On 11/15/13, 8:08 PM, Marvin Humphrey wrote:
> Greetings, VXQuery folks,
>
> Since volunteering as Mentor, I've been scanning through the archives of your
> dev list in order to come up to speed on your project.  It's been a pleasant
> read: communications are respectful, newcomers are welcomed, technical
> concepts are explained cogently and patiently.  The integration of Preston
> into the team has been very well done.
>
> Nevertheless, I may have a suggestion that could help you out.  Here's a quote
> from Vinayak from the release thread on general@incubator...
>
>      http://s.apache.org/b0I
>
>      [...] In fact a lot more work gets done on the project than what appears
>      on "visible" forums like mailing lists.  We use IM and Skype much more
>      than we use mailing lists.
>
> ... here's something from Till back in July on this list...
>
>      http://s.apache.org/Xzd
>
>      Wrt to the other points you mentioned, collaboration seems generally
>      effective (albeit not always on the list), technical infrastructure is not
>      a big problem, and most things I learn about ASF culture I learn from
>      discussions on general@i.a.o.
>
> ... and here's another quote from Till back in January 2012:
>
>      http://s.apache.org/oO0
>
>      Hi Jukka,
>
>      you are right, the consideration hasn't been happening on the list, so
>      Apache-wise it didn't happen.
>
> In that last excerpt, Till is making a reference to a popular maxim at Apache:
> "If it didn't happen on the dev list, it didn't happen."  (Sometimes rendered
> with minor variations such as "on a mailing list".)  Apache Board member
> Bertrand Delacrataz and current Apache President Ross Gardler explain[1]:
>
>      http://grep.codeconsult.ch/2011/08/05/how-to-fix-your-project-collaboration-model/
>
>      In an ASF project, all decisions are made on a single developers mailing
>      list.
>
>      Backchannel discussions are inevitable: someone will meet a coworker at
>      the coffee machine, people attend conferences, talk on IRC, etc. There’s
>      nothing wrong with that, but the rule is that as soon as a discussion
>      turns into something that has impact on the project, it must come back to
>      the dev list. The goal is for all project participants to have the same
>      information from a single source.
>
>      http://osswatch.jiscinvolve.org/wp/2012/05/08/what-makes-a-community-led-project-work/
>
>      ‘If it didn’t happen on the dev list, it didn’t happen’ – meaning no
>      decision about the project can be made outside of the public development
>      list. Proposals can be drawn up elsewhere, but decisions occur on the
>      public list. Academic projects, like open source projects in general,
>      often involve collaborators from a variety of geographic regions. This can
>      make it difficult to ensure that everyone is kept informed and engaged.
>      Apache projects require that all significant decisions are made in public
>      so that no participant (or potential participant) is excluded from the
>      process.
>
> Small, tight-knit communities sometimes have difficulty adapting to a
> development model where mailing list discussions are central.  Even when the
> participants have a lot of experience collaborating in distributed
> environments and are open to new ideas, it takes conscious effort:
>
>      http://s.apache.org/vr
>
>      Community growth is a difficult problem that is central to the Apache
>      mission, and it will be an important challenge for the proposed Aurora
>      podling since all the initial contributors work for the same company
>      (Twitter).  It will be tempting to make architectural decisions in private
>      for the sake of efficiency, but doing so will stunt the project's growth.
>      It's important to hold project discussions out in the open where as
>      many people as possible can witness them and potentially jump in.
>
> Apache is a great place to get involved because our projects are not just open
> source, they are open governance.  It is fundamental to our meritocratic model
> that if someone makes major contributions and collaborates well, eventually
> they will be given a governance stake in the form of PMC membership[2].
> Together, the PMC determines the direction of the project, within the context
> of the larger community.  That's not possible when crucial information is not
> being made available to everyone.
>
> So, I think there's may be an opportunity here.  VXQuery has appeared at times
> to have a problem with low activity because mailing-list volume is sparse.
> That can dampen enthusiasm, discouraging people from getting involved or
> staying involved.  But apparently, there is more going on than meets the eye.
>
> I did not get the impression when reading through the archives that anyone was
> deliberately being secretive -- in fact, had you folks not volunteered that a
> lot of private-channel discussions were happening, I might not have guessed.
> How about making an effort to increase the transparency of your development
> communications?  A lot of possibilities could open up.
>
> Marvin Humphrey
>
> [1] As supplementary material, here are a couple general@incubator discussions
>      on the role of real-time communications:
>      http://markmail.org/message/kt73gkrjhsczsjbo
>      http://markmail.org/message/gpg67b7amoqlgeld
>
> [2] http://www.apache.org/foundation/how-it-works.html#meritocracy
>