Puppet users - May 2011 - Changing up some things around Puppet Labs's Open Source Software

One of the largest challenges we''ve continually faced at Puppet labs is
trying to find a good balance in splitting the development team''s time
between the (currently small amount of) commercial software, and the
(much larger amount of) open source software.  This balancing act has,
unfortunately, affected being able to get a number of the excellent
contributions from people outside of Puppet Labs the attention that they
deserve, and also affected being able to give the internal
"commercial"
development the attention it deserves to further Puppet Labs as a
business.

As a step towards simplifying the decision towards how to divide our
time, we''re dividing our responsibilities instead.  We''re
splitting the
team to form one dedicated to owning the open source projects, focused
on their quality, frequency of delivery, and ease of contribution.

This team''s long-term goal is to build "outside"
contribution, and
generally ensure that we have a healthy and active open source
community.  One of the short-term effects of this is that it will be
much clearer who will be responsible to the community for making sure
that you get the interactions you''re looking for, and that the things
you care about are making their way into the various open source
projects.  Right now this Open Source team consists of Josh Cooper, Nick
Lewis, and myself.

As the "Open Source" team, we''re planning on sending periodic
updates to
the puppet-dev mailing list (and possibly user) with the results of our
planning meeting (what we roughly plan on working on over the coming
iteration), and with information similar to Git''s "What''s
Cooking"
updates[1] (what''s in the repository pending release).  We
haven''t
figured out with what frequency to send these updates (other than the
results of the iteration planning meeting).  If you have any thoughts on
how frequently you think this information would be useful, we''d love
the
input.

We''re also toying around with some ideas on how to get better
visibility
into the daily stand-ups we have.  We haven''t had time to think about
this one too much, but so far we''ve got three rough proposals.

 * Have each person do their stand-up check-in on the puppet-dev mailing
   list.

 * Have someone send a stand-up summary to the mailing list after each
   stand-up.

 * Do something akin to the Pivotal Labs stand-up summary blog posts[2].

Again, if you have any ideas, we''d love to hear them.

This isn''t exactly a change (we''ve just been forgetting to
mention it),
but you can see what the current "community patch backlog" looks like
by
going to our Patchwork instance[3].  We''ve been using Patchwork for a
while to keep track of the patches that go through the dev mailing list,
to try and prevent them from slipping through the cracks.  One of our
goals is to get this backlog down to zero, and keep it as close to that
as possible.

Another long-term change that has been mentioned in passing, but hasn''t
really been fleshed out is moving the other teams to be "just normal
contributors".  Having them go through the same contribution process as
everyone outside of Puppet Labs (though with the ability to walk over or
holler, instead of having to email if they need something).

We''ll likely be making more changes in the future to further achieve
the
goal of having a strong/vibrant/healthy open source community, though we
haven''t figured any of this out yet.  If you have any ideas for things
you''d like to see, or comments/suggestions/questions about anything
I''ve
mentioned please feel free to bring them up here, or contact me
personally.

[1] http://article.gmane.org/gmane.comp.version-control.git/171013
[2] http://pivotallabs.com/blabs/categories/standup
[3] https://patchwork.puppetlabs.com/

-- 
Jacob Helwig

On Wed, 25 May 2011 18:14:28 -0700, Jacob Helwig wrote:
> 
> One of the largest challenges we''ve continually faced at Puppet
labs is
> trying to find a good balance in splitting the development team''s
time
> between the (currently small amount of) commercial software, and the
> (much larger amount of) open source software.  This balancing act has,
> unfortunately, affected being able to get a number of the excellent
> contributions from people outside of Puppet Labs the attention that they
> deserve, and also affected being able to give the internal
"commercial"
> development the attention it deserves to further Puppet Labs as a
> business.
> 
> As a step towards simplifying the decision towards how to divide our
> time, we''re dividing our responsibilities instead.  We''re
splitting the
> team to form one dedicated to owning the open source projects, focused
> on their quality, frequency of delivery, and ease of contribution.
> 
> This team''s long-term goal is to build "outside"
contribution, and
> generally ensure that we have a healthy and active open source
> community.  One of the short-term effects of this is that it will be
> much clearer who will be responsible to the community for making sure
> that you get the interactions you''re looking for, and that the
things
> you care about are making their way into the various open source
> projects.  Right now this Open Source team consists of Josh Cooper, Nick
> Lewis, and myself.
> 
> As the "Open Source" team, we''re planning on sending
periodic updates to
> the puppet-dev mailing list (and possibly user) with the results of our
> planning meeting (what we roughly plan on working on over the coming
> iteration), and with information similar to Git''s
"What''s Cooking"
> updates[1] (what''s in the repository pending release).  We
haven''t
> figured out with what frequency to send these updates (other than the
> results of the iteration planning meeting).  If you have any thoughts on
> how frequently you think this information would be useful, we''d
love the
> input.
> 
> We''re also toying around with some ideas on how to get better
visibility
> into the daily stand-ups we have.  We haven''t had time to think
about
> this one too much, but so far we''ve got three rough proposals.
> 
>  * Have each person do their stand-up check-in on the puppet-dev mailing
>    list.
> 
>  * Have someone send a stand-up summary to the mailing list after each
>    stand-up.
> 
>  * Do something akin to the Pivotal Labs stand-up summary blog posts[2].
> 
> Again, if you have any ideas, we''d love to hear them.
> 
> This isn''t exactly a change (we''ve just been forgetting
to mention it),
> but you can see what the current "community patch backlog" looks
like by
> going to our Patchwork instance[3].  We''ve been using Patchwork
for a
> while to keep track of the patches that go through the dev mailing list,
> to try and prevent them from slipping through the cracks.  One of our
> goals is to get this backlog down to zero, and keep it as close to that
> as possible.
> 
> Another long-term change that has been mentioned in passing, but
hasn''t
> really been fleshed out is moving the other teams to be "just normal
> contributors".  Having them go through the same contribution process
as
> everyone outside of Puppet Labs (though with the ability to walk over or
> holler, instead of having to email if they need something).
> 
> We''ll likely be making more changes in the future to further
achieve the
> goal of having a strong/vibrant/healthy open source community, though we
> haven''t figured any of this out yet.  If you have any ideas for
things
> you''d like to see, or comments/suggestions/questions about
anything I''ve
> mentioned please feel free to bring them up here, or contact me
> personally.
> 
> [1] http://article.gmane.org/gmane.comp.version-control.git/171013
> [2] http://pivotallabs.com/blabs/categories/standup
> [3] https://patchwork.puppetlabs.com/
> 
> -- 
> Jacob Helwig
It was brought to my attention that we may not have made an aspect of
things quite as clear as we had intended.

The "commercial" team will continue to work on features & bugs in
both
the open source and commercial projects.  (Puppet Labs does have support
contracts and paying customers after all.)

The "open source" team will work on the open source projects with the
goal of furthering them as open source software.  The primary goals of
the team will always be encouraging outside contributions to the open
source codebases, and making the open source software better on its own
merits.

-- 
Jacob Helwig