use the word 'coordinator' than? Words are for sure important, but even more important is imo how the community _acts_. And that worked pretty well so far (attracting 3 new contributors itmt).
LieGrue, strub --- On Wed, 12/1/10, Dan Haywood <[email protected]> wrote: > From: Dan Haywood <[email protected]> > Subject: Re: r0.1 tracking in JIRA > To: "Bernd Fondermann" <[email protected]> > Cc: [email protected] > Date: Wednesday, December 1, 2010, 10:27 AM > Hi Bernd, > It's a good point you make. > > In the discussion thread I posted earlier on for v0.1, I > was careful to > use the correct language... it's about ownership of a > getting a > component ready for the v0.1 release, rather than owning it > for all time. > > For the list below, I copied out details from the JIRA > system, where > there is a field for component owner which I've > populated. I'm > wondering if I ought to blank it out? > > On the other hand, we do want to be able to say: "this > person knows the > most about such-and-such a module", without it completely > being their > responsibility for ever more. Do you have any ideas > on the best way to > do that? > > Thx > Dan > > > On 01/12/2010 10:16, Bernd Fondermann wrote: > > Note from the peanut gallery: Please make sure that > 'lead' is not > > interpreted as 'having code ownership', or 'is > telling/demanding how > > that specific part of the project should evolve'. > Leaving modules > > explicitly without a shepherd could attract new people > to jump in - > > and growing community is one of the goals of > Incubation. > > > > Thanks, > > > > Bernd > > > > On Wed, Dec 1, 2010 at 01:24, Dan Haywood<[email protected]> > wrote: > >> All, > >> Nour, Rob and myself had an skype call yesterday > evening regarding an > >> approach to manage the v0.1 release. The > plan we came up with was to use > >> JIRA, with a ticket for each main component (or > group of components). I'm > >> posting this here for visibility/comments. > >> > >> The proposal for the 0.1 release is to create a > JIRA ticket for each of the > >> following: > >> > >> Core (Lead: Dan Haywood) > >> AppLib (Lead: Dan Haywood) > >> Defaults (Lead: Dan Haywood) > >> Alternatives: Bytecode (Lead: Dan Haywood) > >> Alternatives: Embedded (Lead: Dan Haywood) > >> Alternatives: ObjectStore: NoSQL (Lead: Robert > Matthews) > >> Alternatives: ObjectStore: SQL (Lead: Kevin > Meyer) > >> Alternatives: ObjectStore: XML (Lead: Robert > Matthews) > >> Alternatives: ProfileStore: XML (Lead: Robert > Matthews) > >> Alternatives: ProgModel: Groovy (Lead: Dan > Haywood) > >> Alternatives: ProgModel: Wrapper (Lead: Dan > Haywood) > >> Alternatives: Security: LDAP (Lead: Robert > Matthews) > >> Viewer: BDD (Lead: Dan Haywood) > >> Viewer: DnD (Lead: Robert Matthews) > >> Viewer: HTML (Lead: Robert Matthews) > >> Viewer: JUnit (Lead: Dan Haywood) > >> Viewer: Restful (Lead: Dan Haywood) > >> Viewer: Scimpi (Lead: Robert Matthews) > >> Viewer: Wicket (Lead: Dan Haywood) > >> > >> NB: this combines all the core components into a > single ticket; all the > >> default components into a single ticket, it > excludes jpa objectstore, > >> mongodb objectstore, and remoting. > >> > >> Each of these tickets will be used to track the > status of: > >> 1- Documentation (docbook PDF + site APT) > >> 2- Review package names, Maven artifacts IDs, > copyright notices. > >> 3- For the alternatives and viewers, should have a > module in the > >> support/prototype project > >> > >> We also need a ticket for the archetype itself, to > reverse engineer from > >> support/prototype into an archetype. > >> > >> When all of these tickets are complete, then - in > theory - r0.1 will be > >> ready for release. > >> > >> > >> If everyone is happy with this, then Nour has > volunteered to enter these > >> tickets into JIRA and to track the status through > to v0.1 release. > >> > >> Cheers > >> Dan > >> > >> > >> >
