On Feb 3, 2006, at 4:54 PM, Katie Capps Parlante wrote:
Over on the scooby and cosmo lists, folks are having a conversation
about whether or not to merge scooby/cosmo into one project, or to
keep the two projects and start a 3rd project (snarf) that combines
the two into one download.
I think the conversation raises some interesting questions that we
might discuss here on the general osaf list. In particular, how do
we define what a "project" is?
I'll throw out a definition, based on some things that people
mentioned:
* A project has its own roadmap, release schedule, and requirements
planning
* A project has its own space to communicate about the project (irc
channel, mailing list)
* A project has its own development team, or set of people who are
coding on the project (set of committers)
A project has its own community, which includes code contributors,
and designers, testers, documenters, localizers, and users. The
community around a project is more than the developers.
* A project has its own bugzilla product
* A project has its own website/wiki starting point
* A project has its own license
* A project has its own svn repository (one or more?)
* A project may provide one or more different types of downloads
* A project has its own level of formality (more or less agile,
more or less formal product planning)
Right now Chandler, Cosmo and Scooby operate as separate projects.
PyICU, PyLucene, Zanshin, M2Crypto, are also all independent
projects, with at least some of these trappings.
Across projects, we'd like to have:
* A consistent overall vision and strategy for how the projects fit
together
* One design/product team to support all projects (one team to
provide some continuity in this vision)
* One qa team to support all projects (providing more or less
support to some projects)
* One build/release team to support all projects
For QA and build, I'm not sure that this is the case, except in a
coordination kind of role. One of the benefits of open source
development styles is the ability to scale up QA/testing. Once we
start to see this happen, you are going to see people who focus on
specific projects as opposed to all of them. At that point our QA
staff out to be functioning in a role more like the Issue manager
described by Fogel <http://producingoss.com/html-chunk/share-
management.html#issue-manager>. Either that, or we are very short
staffed for QA.
I think that this will also be true for aspects of build, again once
interest ramps up.
* A consistent overall governance policy across projects
* A legal shield that protects project contributors from lawsuits -
that the Foundation part of OSAF
* A single set of infrastructure/IT support
* A single press/pr contact
Thoughts?
Cheers,
Katie
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general
----
Ted Leung Open Source Applications Foundation (OSAF)
PGP Fingerprint: 1003 7870 251F FA71 A59A CEE3 BEBA 2B87 F5FC 4B42
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general
