incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Incubator structure (was Re: Vote on personal matters: majority vote vs consensus)
Date Mon, 01 Apr 2013 00:20:25 GMT
On 31 March 2013 17:08, Mattmann, Chris A (388J) <> wrote:

> Why is it so hard to see that the board is already watching those 22
> nascent projects in the same manner they watch the 137 TLPs?

Because they are not watching with the same manner. They are delegating a
huge range of tasks such as IP oversight and mentoring to the IPMC.

> Ross says the Board pays less attention to these (by implication) than
> say the 137 TLPs at present. Ross is one Director. Good for him.

I, personally, pay as much attention to the PPMCs as I do to TLPs. I'm
active in the IPMC and thus have more visibility. That doesn't mean they
should be expected to by me or by anyone else.

> I know other directors (Greg IIRC at least) didn't want the Incubator
> specific podling reports to go away (and to only have the summary
> at the top of the Incubator report).

I don't think any of the Directors want them to go away. But board reports
are not what the IPMC is about. That is the reporting process within the
foundation and provides the level of oversight into the PPMCs that the
board requires. But the IPMC does *much* more than submit a monthly board
report with a verbatim copy of the podlings individual reports.

> What i can see, and what I think even Upayavira and Ross
> agree
> with -- and you too Benson -- is that there is a grave problem here and it
> needs' a fixin'. My deconstruction proposal does that.

No, I do not agree there is a grave problem. I have denied that repeatedly.
The IPMC has problems, but in the main it works extremely well.

Upayavira does get it right in his email when he says:

"To summarise. The incubator *is* broken (but not necessarily beyond
repair). We need as many mentors as we can get, and a smaller group of
people who are delegated responsibility for the incubator. The board
wants a group of folks to take responsibility for overseeing the early
life of communities at the ASF. These are, to my mind, the criteria that
we should be using to evaluate any suggestions as to how the incubator
should be structured. If it doesn't meet these, it won't float."

The rest of his excellent mail got me thinking.

When we discussed this before Jukka took over there was a push for ComDev
to take on the documentation of policy, best practice and process. As VP of
ComDev at the time I pushed back. I was concerned that moving the process
of documentation wasn't going to make any real difference. However, I did
say that if the IPMC could start to get its house in order then I agreed
ComDev would be the right place for this.

I think the IPMC has resolved many of its problems over the last 12 months.
So it is time to revisit that suggestion. However, I would suggest we
revisit in the light of Upayavira's excellent mail, specifically:

 "It seems to me there are two principal roles that the Incubator has had
- one is to help define processes, and social mores. ... The second role is
to provide 'oversight' or
'supervision', providing a layer above mentors to ensure that podlings
are progressing and that mentors are active. It is this latter role that
is still very much needed, as we would expect there to be more issues in
newer podlings than in established TLPs. It seems to me that the board
*wants* to delegate this responsibility to another committee."

The first of these two roles is, for the most part, where the IPMC can
sometimes reach stagnation and can become extremely confusing to podlings
(getting multiple answers for one question for example). Maybe it is time
to move this to ComDev and take that area of conflict away from the IPMC.
This would leave the IPMC to focus on providing the oversight that Jukka's
new processes have started to heal and Benson is now fine-tuning.


Ross Gardler (@rgardler)
Programme Leader (Open Development)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message