We fully agree and understand the meaning of the community. Communication
is vital.
But my main point is we still need to know the desired process flow of what
is expected. To date we have not been informed of the proper steps. So
having a process outlined is important.
This isn't something we're doing on the side, (supporting VCL - the
production system at NCSU and it's development), it is our full-time focus.
We'll start working on the suggestions Alan mentioned below as a starting
point, but again we'd appreciate a quick bullet list of do's and don'ts as
soon as someone gets the chance.
Aaron
--On January 6, 2009 11:21:00 AM -0500 Kevan Miller
<kevan.mil...@gmail.com> wrote:
On Jan 6, 2009, at 10:13 AM, Alan D. Cabrera wrote:
You've made a good point. Rather than generating the process in an
ad hoc fashion, we should whip one up as soon as possible.
There are no standard development processes in the ASF. There are
rules about releases and what can go into them. The ASF likes to
let projects define the specifics how they want to work. There are,
however, guiding principles that influence how projects define their
process. The top priority is building and maintaining community.
This priority takes precedence over everything else. It can be
frustrating at times and this is usually the hardest for new
projects to grok. But it is so important that building and
maintaining community takes equal weight in the eyes of the
Incubator PMC to code base vetting. So important that this is the
usual reason that incubated projects take longer than expected to
graduate or, worse, are withdrawn.
So with that in mind, here's a phrase that has me worries "We have a
lot of work/submissions over the next couple of months". There's
been no discussion on this list about architectural/feature
additions and modifications. This worries me. We're not a
SourceForge where code can be developed externally then dumped into
our repositories when it's done.
With that said, I invite the current project team to come up with a
development process that makes planning and development
transparent. You should be thinking of ways to get more members of
the community involved in this project. Part of this is requiring
architectural and development conversations in public on this list.
Simply posting roadmaps and Jira issues won't do. You should not be
having development meetings at your office as you previously have
done. It precludes involvement of the community.
Finally, some tactical advice. Never work on anything unless
there's a Jira issue for it. When you check in your code place the
Jira issue number in the checkin comment, e.g. "VCL-325 added SNMP
MIBs to storage management". This allows products such as Fisheye
to index the two together. Road maps are great. Architectural
diagrams are great. Creating Jira issues for everything that you
will do or want to do is great. It allows people to volunteer to
pick up work or offer to help. I will remind you that community is
the raison d'etre for VCL being here. This means that no person
"owns" a chunk of technology. If a person is working on a a corner
of this project and someone else wants to help that person must be
accommodating and share the work; there is no such thing as "dibs"
on an area of architecture.
Alan raises excellent points. The absolute key is communication via
public discussion on the dev list. Wiki roadmaps and jira issues are
nice, but not sufficient. Public discussions are what allow "communities"
to form and grow.
Some of the specifics (e.g. Jira issues for all svn commits) are a
community decision. There's no getting around the communication
requirement.
--kevan
