Graduation checklist thoughts...

[dkulp]

Now that I'm pretty much "done" with the tasks on the post graduation
stuff at:
http://incubator.apache.org/guides/graduation.html
I have a few things to say:

First, THANKS A TON to everyone that had contributed to that.  It's very
well done and quite complete.   It's obvious that a lot of time, effort,
and knowledge went into it.   Honestly, my brain is half fried from
everything I've learned over the last week or so.   Without the list
there, this could have been a very frustrating period.

That said, I did run into a couple "snags" that probably should be
addressed on the checklist:

1) The "private" list.  (I haven't completely figured this one out yet)  
CXF already had a private list, but it obviosly includes some folks that
are not on the new PMC.  For example, a couple of the mentors that did
not elect to join the new PMC, a few folks that left, etc... I haven't
tackled how to edit this yet.   One option is just to have
infrastructure do it as part of the TLP request, but it might be good to
point the new chair off to the ezlm docs on how to do this.

2) I haven't figured this one out yet either.  Once the mailing lists are
migrated, confluence should be updated to email to the new commits list
(providing you had it emailing the old commits list).   I'm a confluence
admin, but I don't have the experience for this.   Again, this could be
added to the TLP INFRA jira request or documented for the new Chair.

3) Similarly, the JIRA for the project should be updated to send it's
notices to the new lists.   The JIRA group should also be updated to
reflect the proper set of committers.  I did figure this out for CXF,
but should be documented or added to the TLP request.

In general, I'm the type of person that likes to "learn new things" and
tackle as many of the smaller tasks myself rather than bothering the
infrastructure folks with "trivial" tasks.  (the infrastructure folks
are busy enough as it is)   Thus, I like the "document for the new
chair" approach, but I do understand not everyone likes that approach
which is why adding it to the TLP request is not a bad idea.  


Anyway, I just wanted to share that experience.  In general, the list is
very good and I appreciate the effort that went into it as well as the
efforts of the infrastructure folks to get everything done in a timely
manner.  

Thanks!
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@...
http://www.dankulp.com/blog

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[Brett Porter]

2008/4/26 Daniel Kulp <dkulp@...>:
>  1) The "private" list.  (I haven't completely figured this one out yet)
>  CXF already had a private list, but it obviosly includes some folks that
>  are not on the new PMC.  For example, a couple of the mentors that did
>  not elect to join the new PMC, a few folks that left, etc... I haven't
>  tackled how to edit this yet.   One option is just to have
>  infrastructure do it as part of the TLP request, but it might be good to
>  point the new chair off to the ezlm docs on how to do this.

IMO, this should be done as a matter of course during the podling (for
those that left), and for mentors just at their own discretion (their
entitled as members to be subscribed to the list if they wish to
continue to be)

>
>  2) I haven't figured this one out yet either.  Once the mailing lists are
>  migrated, confluence should be updated to email to the new commits list
>  (providing you had it emailing the old commits list).   I'm a confluence
>  admin, but I don't have the experience for this.   Again, this could be
>  added to the TLP INFRA jira request or documented for the new Chair.
>
>  3) Similarly, the JIRA for the project should be updated to send it's
>  notices to the new lists.   The JIRA group should also be updated to
>  reflect the proper set of committers.  I did figure this out for CXF,
>  but should be documented or added to the TLP request.

I think these are both left up to the project intentionally (since
every project can be different), and it's one of the reasons people in
the project have enough admin privileges to change them. From what I
understand of the TLP request - it's really to get the things done
that only infra can do (and to leave everything in a consistent state
- eg mails to the old lists from other systems still work). It's worth
documenting this in the instructions, perhaps linking to some docs
about administering confluence etc., but probably not making it part
of the (already long) TLP request.

>  Anyway, I just wanted to share that experience.  In general, the list is
>  very good and I appreciate the effort that went into it as well as the
>  efforts of the infrastructure folks to get everything done in a timely
>  manner.

I'll second that, having just been a part of 2 myself (even though
they weren't from the incubator, the list was still helpful).

Cheers,
Brett

--
Brett Porter
Blog: http://blogs.exist.com/bporter/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[robert burrell donkin-2]

On Sat, Apr 26, 2008 at 4:44 AM, Brett Porter <brett.porter@...> wrote:
> 2008/4/26 Daniel Kulp <dkulp@...>:

<snip>

>  >  Anyway, I just wanted to share that experience.  In general, the list is
>  >  very good and I appreciate the effort that went into it as well as the
>  >  efforts of the infrastructure folks to get everything done in a timely
>  >  manner.
>
>  I'll second that, having just been a part of 2 myself (even though
>  they weren't from the incubator, the list was still helpful).

and thanks to everyone who takes the time to help us improve the
process: the feedback loop from participants is vital.

i've updated http://incubator.apache.org/guides/graduation.html#project-first-steps
with some more content but it'll be a few hours till it's sync'd.
please take a loop and either patch or post comments to the list.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...