On 12/22/2014 11:42 AM, Roman Shaposhnik wrote:
Hi!
before answering Ross' proposal, I'd like to remark that I was holding
off on replying to see whether viewpoints that we haven's seen before
would emerge. It seems that they didn't. It seems that we're still limited
by the following options wrt. resolving mentors AWOL issues:
1. get rid of IPMC altogether and move to the pTLP model
2. make this a poddling issue: if a poddling fails to hunt down ALL
the mentors for a sign-off -- reject its report
-0.5 to punishing podlings for the failings of mentors. That would
really suck.
3. patch the current process with starting to drop the mentors from
the project who don't sign off. This will essentially serve
as a heartbeat for mentors (now, in my opinion it'll quickly
deteriorate into mindless tick-offs -- but at least it does not harm).
... who don't sign off N times, perhaps? Missing one should be a
warning, two a scolding, three the boot, perhaps?
FWIW, I personally think #2 is a useless middles ground and if we
really feel like #2, we may as well man up and do #1. Frankly, I'd
be appalled to remain part of IPMC that treats its podlings like #2
without providing even the slightest accountability for its own members.
+1
Thus, to me, the choice is really about #1 and #3. So perhaps, the
path forward is to try #3 first and then, if things don't improve, go
all the way to #1. Please let me know what do you think.
Yes. Agreed.
And now to comment on Ross's proposal. The only one that addressed
my original issue of lack of clear R&R understanding (which I think
everybody else, with an exception of folks bringing up #1 is avoiding):
On Fri, Dec 19, 2014 at 11:00 AM, Ross Gardler (MS OPEN TECH)
<ross.gard...@microsoft.com> wrote:
Strawman:
What if a mentor is *required* to be an active participant of the project. That
is contributing code,
voting on releases and generally engaging with the community, they would be a
better mentor
since they have a vested interest in the project itself.
Well, than I suggest we solicit an opinion on this list of how many mentors
will remain if the requirement is to be put in place. I can tell you this much:
personally I will have to resign from every single poddling I am currently
mentoring. There is absolutely no way I can promise the level of commitment
that goes beyond helping them with 'the Apache Way' and releases. IOW,
if I were to be required to understand their technology -- I don't think I can
stay.
I'm considering serving as a mentor, because I think that my experience
at the ASF would benefit an incoming podling. If I was required to be a
coder on that project, I would no longer be able to participate in that
capacity, as my coding abilities have atrophied over the last few years.
I also object strongly to the use of the phrase "contributing code"
becoming part of any written policy. (#INCLUDE standard conversation
about documentors, marketers, event planners, community managers, etc,
being every bit as meritorious as coders.)
Sure, we might reduce the number of projects coming into the foundation
but (IMHO) that is not a problem. Our goal as a foundation is not to be
large, it is to be high quality.
But it is to be high quality on the level of understanding of the 'Apache Way'
which has very little to do with the quality of code, documentation or any
other piece of technology.
We could scrap the role of shepherd and change the role of mentors. A team
of 9 mentors would meet monthly to review *all* podlings reports (as submitted
by the champion). Their responsibility is not to engage with the projects but to
review the reports crafted by the champion. Any follow up actions would be
taken by a single mentor and podlings (especially the champion) are expected
to address the issues raised.
I actually like this proposal, but only if we can cut out the
middleman alltogether.
What you're describing is essentially pTLPs. Which is a fine idea.
I like the proposal a lot too, and almost proposed it myself. It's a
mirror of what the board does, obviously, and raises the bar a little
when it comes to podling reports. It also gives the podlings a little
more idea of what to expect once they do graduate.
The champion is still answerable to the podling community.
Where conflict arises within the community they can call upon the IPMC
mentoring team to ask for independent guidance.
Let me ask you this: do you think it would be worth our while to try this
without any other changes? IOW, make #2 a champion's problem, instead
of poddling's problem? No other changes needed.
I look forward to the PMC tearing this strawman proposal apart and (most
importantly)
suggesting alternatives
That was my expectation as well. Sadly, I don't think we've got too many
alternatives :-(
Roman, please forgive me absence from this conversation. I started the
thread, and then went on Christmas vacation. I am still on vacation for
another week, but will attempt to keep up with the conversation here,
and not abandon the thread I started. Please also forgive the dozen
responses that I'm dropping all at once.
I care deeply about the outcome of this conversation, and it certainly
sounds like several other people do, too, but the timing was unfortunate.
--
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
