[Buildbot-devel] Developer Recruitment (summit topic)

[Dustin J. Mitchell]

I've made no secret of my desire to share responsibility for parts of
Buildbot.  Currently, I see a lot of patch submissions, but in many
cases bugs are found that I am ill-equipped to solve.

My proposed approach is to formalize some of the roles and policies
within Buildbot.  The idea is to break responsibilities down into
manageable chunks that others can take on, and thereby parallelize
Buildbot's development.  Here's my plan -- let me know what you think!

First, break Buildbot into a collection of components - basically
those in http://buildbot.net/trac/wiki/TicketKeywords, with some
additions.  Each component will have at least one maintainer, with
that information recorded in the source tree.  Components for which
there is no maintainer and for which there are outstanding bugs will
be scheduled for deletion after three releases with no maintainer.
This should both pressure folks to step up to maintain components
about which they are knowledgeable *and* clean out components that are
unused.  We have a number of maintainers already - this will just make
the relationship more formal.

Next, recognizing that not everyone is an expert Twisted Python
hacker, define a number of roles not limited to developers:
 - core maintainer (who, among other things, will respond to pull requests)
 - component maintainer
 - tester (writing and/or running tests)
 - packager
 - buildbot.net admin
 - trac admin (help me with ticket wrangling!)
 - security incident handler
(others?)

Each of these would come with various permissions.  This basically
gives me a set of rules to say who gets commit rights, who gets root
on buildbot.net, who gets +v in #buildbot, etc., rather than making it
arbitrary.  For the moment, I intend to be the one assigning roles to
people.

I welcome your thoughts.  Am I over-engineering things?  What else can
I do to make the project more amenable to distributed authority?

Dustin