Apologies in advance for slightly crossing threads here.
Even though I have already sent quite a lot of emails on this subject
(12 over the past week!), I feel I must reply to some of the concerns
and opinions expressed in the last few emails. I do not like it when
concerns are answered with the notion that it is perhaps caused by the
concerned party being uneducated, as I believe there are deeper issues
at play here. Nor do I agree with any notion that the IPMC should be a
rubber stamp.
But let's get some facts straight first:
- The champion of the project created a DISCUSS thread prior to a
potential vote. Not a VOTE thread, but a DISCUSS thread. This implies
that a subject is to be reviewed and discussed.
- During this discussion thread, concerns were raised by people outside
of the IPMC.
- Members of the IPMC looked into the concerns, as any governing body
should, and while doing so, discovered other issues that were brought to
the attention of the podling. These issues ranged from bad wording,
which were unfortunately favorable to a specific company, to more
procedural issues in maintaining transparency in development.
- Some of these issues were fixed, some were debated/refuted, and some
are 'pending' later review (chiefly cultural and procedural issues raised)
The fact that the IPMC members found other issues while investigating
concerns does not, in my view, equal 'micro management'. I think it
shows that having people outside the specific podling look into it can
shed some light on matters that were perhaps overlooked by mentors, and
that is a good thing. Very specific issues were highlighted because they
showed exactly where the supposed disconnect in procedure was. I believe
having specific data points to present helps a great deal in fixing
procedures.
We can debate whether the IPMC should have found these issues earlier,
as Ross rightfully suggests, but nonetheless, the following is (I hope)
true:
The IPMC, just like the board of directors, trust the mentors - just
like the board trusts the PMCs - to do their best in reporting the true
status of a podling/project. The IPMC, just like the board, does not
rubber-stamp blindly. If concerns are raised, the IPMC, just like the
board, will look into issues, and if that search yields anything worth
asking about (even if that turns out to be some other issue found during
the investigation), then the IPMC, just like the board, will ask the
podling/project whether this is true and whether they are currently
working on fixing it or will fix it.
I fail to see the disconnect, nor do I see it as 'punishment from up
high' as was suggested. There were a few emails where the tone should
have been more polite or diplomatic (FOSSers can get quite grumpy, we
should try our best not to), but on the whole, this discussion has been
one of facts (specifically an inquiry into why the findings of some
people are inconsistent with the findings of others) and policy.
We all have day jobs, we have hobbies, we have family, we have beds we
sleep in for quite a lot of hours every day. That coupled with our other
commitments to ASF projects makes it nigh impossible to stay up to date
with what's going on in every single podling, which in turn means that
when we finally do, every single thing, that should have been mentioned
perhaps months ago, suddenly rains down on the podling within a matter
of days. This is indeed unfortunate and not always very fair to the
podling, but it is a result of how the incubator works and how people work.
This thread has been long, and I'm not interested in having it go on
forever. The IPMC has given feedback to the podling, the podling has
either complied or promised to comply with this. Given enough time for
procedural changes to become visible and consistent, I think the mentors
should then start a vote on graduation.
With regards,
Daniel.
On 2015-07-25 22:27, Roman Shaposhnik wrote:
On Sat, Jul 25, 2015 at 2:10 AM, Branko Čibej <br...@apache.org> wrote:
On 24.07.2015 21:00, Konstantin Boudnik wrote:
An an active mentor of the podling I do support the graduation. The last, to
my knowledge, concern expressed was about insufficient open discussions of the
new features on the dev@ and that has been addressed by [1]
WRT your observation: I do think the diversity part in the graduation
requirement is moot and, as this discussion shows, quite counter-productive. I
will start a separate [DISCUSS] about reconsidering its presence in the
guidelines.
[1] http://s.apache.org/vYK
Seconded.
Makes three of us. As a mentor, I fully support graduation of this podling.
Thanks,
Roman.
P.S. Also, after going through the thread, I still maintain that I have nothing
to add to what I've already said wrt. perception on what diversity requirement
really means. As somebody who's been with the IPMC for almost 5 years now
I would like to make an observation: we seem to get confused from time to time
on what the real purpose and status of the IPMC is. Perhaps this corresponds
to the waves of new folks joining us in which case I'm totally happy
with us educating
them on those things (I just hope it doesn't turn into an "Eternal September").
Perhaps instead of trying to forever hunt for yet another corner case
in an attempt
to fully document the incubation process we all could just remember that:
#1 our ultimate mission is to help the ASF board not waste their time with
communities that, if looked at as a TLP, would surely trigger
a board action
of some kind.
#2 The #1 goal is achieved via mentorship. In fact mentorship is
not even required
as the case of Zest (and hopeful Yetus soon) demonstrated.
#3 When mentorship is required IPMC entrusts the mentors to guide
the project to
graduation. It should should let them do that.
#4 IPMC should NOT be confused with an ASF project. This is
incoherent given its
size and composition. The Incubator is a curriculum, not a community.
In short, I'd like to see IPMC behave more like the ASF board, and
provide an effective
oversight over the mentors not micro management. This is a tough
balance, I know.
Yet, I'm sure that folks here in general mean well and are capable of
striking that very
balance.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
