Bart Smaalders wrote:
> Do you seriously propose that we review each one of these with PSARC
> ahead of time? When we have no idea which ones we'll keep? Before we
> discuss them on opensolaris mailing lists?
Yes and Yes and Yes, if you define "review" as "keep PSARC informed".
The development process we try to follow is
Come up with an idea, tell people you are going to start
thinking and prototyping and doing the idea, interact with
various stakeholders to better understand the ramifications
of your idea as you flesh it out into a concrete proposal,
review and get commitment on that proposal, go off and do
the design and implementation of that proposal, and finally
integrate it.
The way we have chosen to "tell people you are going to start thinking
and prototyping and doing the idea" is to file a 1-pager. Many people
and processes key off of that action, including (but not limited to)
the ARC.
As part of your prototyping, you need to interact with your various
stakeholders. Some times this includes the ARC as well as customers
and consumers. You don't ask any of these groups for a review or
commitment *at this time*, but you *do* need to work with them to make
sure that both you and they are on the same page. In ARC terms, this
interaction is called "preinception review" or "umbrella case" or simply
asking for an informational/brainstorming meeting. For many projects,
the simple act of filing the 1-pager is sufficient interaction.
It is only when you finally have a concrete proposal that it is
appropriate to ask the ARC to make a decision on your idea - that is
when the usual inception and commitment review dance comes into play.
If you have done a good job with your stakeholder education and
involvement up to this point, these reviews will be simple and
trouble free. (It is also perfectly OK to withdraw projects
won't be kept past the prototype stage - closure on things we
won't be doing is just as useful as closure on the ones we will.)
By choosing to NOT submit a 1-pager at the beginning when you
are actually starting to think about your idea, you bypass and
disenfranchise a large set of stakeholders, not to mention the
disconnects and misunderstandings you cause by inventing your own
parallel-but-not-compatible development process. You start to
make all sorts of decisions and assumptions as you go on, and
those decisions are suboptimal simply because you are intentionally
excluding a potentially large set of stakeholders from participating
by keeping them ignorant of your efforts. Worse, other projects,
running in parallel, in other parts of the community, have a more
difficult time of learning about and interacting with the work you
are doing. Case in point: the whole rpm/apt -vs- Blastwave -vs-
Conary -vs- IPS mail storm.
> PSARC is NOT a member of every project team.
PSARC (or maybe OpenSolaris-ARC) *is* a key stakeholder of every
project team that intends to integrate back into OpenSolaris.
If you go off and design something that impacts the architecture
of the OpenSolaris system, AND YOU HAVE NOT BOTHERED TO KEEP
PSARC IN THE LOOP, you will have problems. Come early, come often
means exactly that. It does *not* mean "only come after you have
made all your decisions".
> Engineers communicate through working code.
Good engineers also communicate in other ways, including using the
processes and tools that exist to foster productive interactions
with their key stakeholders. Working in a self-constructed silo
benefits nobody.
To steal a thought from another thread, consider PSARC to be the
/usr/bin of community development - we intend to do all our
development there so that we all can both stay informed and
influence common expectations and behaviors. Going off and
inventing your own /usr/bart development process makes it
hard to discover and use your projects.
-John
