incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <>
Subject Re: Improved Reporting [WAS Re: [VOTE] Park Kato]
Date Mon, 16 Jan 2012 12:39:25 GMT
On Mon, Jan 16, 2012 at 6:56 AM, Robert Burrell Donkin
<> wrote:
> On Mon, Jan 16, 2012 at 11:21 AM, Sam Ruby <> w.
> <snip>
>> I would like to call on everybody to
> <snip>
>>  focus on ensuring that reports
>> submitted are timely and contain all of the relevant information.
> ATM the reports remind me of a poorly edited and reviewed
> reincarnation of the Jakarta Newsletter. What should the report
> contain?

I'll share at a 10 thousand foot view how I review board reports.

First for projects, which I hope that every podling here aspires to be
some day.  The high order bit for me is to see that the project are
self-governing.  A report that says in bold letters that "we have a
big problem, we don't know how to handle it, but we are going to try
X" is an indication that the group is self-aware and attempting to
self-govern.  Groups that do not detect problems or attempt to
minimize them or sweep them under the rug are a concern for me.
Detecting missing parts is hard, so I look for indirect evidence of

In particular, I look for evidence of community and releases.  When a
report says "no releases this quarter" or "no changes in PMC or
committers this quarter", I look to prior reports.  If there is
evidence that there was activity in prior quarters, that is fine and I
look no further.  If I see no such evidence within a year, I begin to
get concerned and ask questions.  I encourage answers to those
questions to go into subsequent reports.

I also look for instances where the report asks for help from the
board or other committees such as legal affairs, treasurer, etc.

Applying that to the Incubator as a whole, clearly releases are not a
concern (inevitably some poding somewhere made a release).  What I do
not see is that the Incubator (as a whole) acts as if it is self-aware
or capable of self-governance.

When reviewing podling reports, I give quite a bit of latitude to
podlings that are less than a year old.  A newly entered podling can
have no clue, make no releases, and that's OK.

Over time, I expect podlings to mature.  In particular, I would like
to see podling reports of the quality I expect from projects to be
coming out before graduation.  In my opinion, many podlings should be
able to graduate within a year.  Podlings that are still here after a
year but less than two years should be able to show signs of forward

If <> is up to date, we
currently have seventeen such podlings.

By two years, podlings should have a very clear idea what they need to
do to graduate.  We have six such podlings.

By three years, podlings should be able to demonstrate that they have
a unique situation and some hope (perhaps even a slim one) that things
will work out.  We have eight such podlings.

We also have two podlings that are over four years old.  RAT looks
like it is going to graduate.  The other is JSPWiki.

JSPWiki needed attention.  I am one of the mentors of that podling,
and hadn't been doing a great job of following up.  Starting in
November/December I made some inquiries, and now in January, there is
some discussion.

Apparently when JSPWiki landed here, the original authors saw that as
an opportunity to do a major rewrite.  Something that they have yet to
complete.  There is some talk of moving to github and continuing that
effort.  There is some talk of returning to the original baseline and
completing that effort.  I am comfortable with either approach.

The last code commits to JSPWiki were: 2012-01-14 (one commit),
2011-12-30 (three commits), 2011-09-20 (three commits).

The above three paragraphs are the types of things I would like to see
in reports.  They would show some evidence of self-awareness.

I am not saying that JSPWiki should be terminated.  I am not saying
that I should be terminated as a mentor.  I am saying that I should do
a better job ensuring that JSPWiki is both self-aware and produces
better reports.

I started this by saying this was how I review reports.  Others may
review them differently. It also is an approximation.  I am well area
that Gump doesn't make releases, and that the Tcl community is stable.

> Robert

- Sam Ruby

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message