Re: Discussion at ApacheCon:BigData

[Joe Brockmeier <jz...@zonker.net>]

On Sat, Oct 31, 2015, at 04:59 PM, Lenni Kuff wrote:
> Thanks for all the comments. Based on the previous feedback, we have
> tried
> to bring any offline discussions back to the dev list and have been using
> the dev list as the forum for any decision making (as David pointed out).
> In addition, Sravya has organized a regular monthly Google hangout [1] to
> help facilitate discussions which may be easier to have face-to-face/over
> the phone. The hangout will be open for anyone to join and all meeting
> notes will be posted back the dev mailing list.

"Have tried" is not the same as actually doing, nor am I comfortable at
this stage saying "yes, as a mentor I feel this group has adopted best
practices from Apache and is going to continue doing this on its own
post-graduation."

"Sravya has organized a regular monthly Google hangout" not quite.
Sravya has sent out an email that appears to have gone directly to VOTE
(no DISCUSS) for a 30-minute hangout. 

Note that this was about a week ago, and none of these hangouts have
actually happened - so it's impossible to judge its effectiveness and
describing it as "regular" at this point is a bit early. 

(As a side note, as much as I prefer discussions happen on a mailing
list - if you're going to do a real-time conversation, I am not sure 30
minutes is sufficient. At least in my experience, it usually takes ~5
minutes for a distributed team to actually join a call and get started,
and if you have any amount of discussion at all it would take some
ruthless efficiency to get through a discussion *and* have time for an
open floor for newcomers to ask questions.)
 
> I apologize, but it's still bit unclear to me - based on the remaining
> criteria you outlined - specifically what we still need to accomplish
> before graduation.

So - the discussion at ApacheCon happened, what, about a month ago? The
types of things we're pointing out are not just checkboxes for the
project to tick off, but fundamental practices we need to see in order
to say "yes, this project is going to behave like an Apache project
after graduation."

Is Sentry producing code? Yes.
Is Sentry producing releases? Yes.
Is Sentry's infrastructure (Web site, Jira, mailing lists, and so on) in
order? Yes.* 

All great! 

The tough one: Is Sentry creating an open and diverse community that
allows anyone to participate? Right now, I don't think Sentry is there.
What I see right now is a podling that has had a fair amount of
communication about development out of the public eye and/or in channels
that are difficult to join for the public at large. 

David and I have given feedback on steps Sentry can take to remedy this.
What Sentry needs to accomplish now is to follow through on this and
build a track record there. (See also [1])

* Pretty sure. I did a quick cursory glance and things look good. 

[1] http://incubator.apache.org/guides/community.html#communication

Best,

jzb
-- 
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: Discussion at ApacheCon:BigData

[Joe Brockmeier <jz...@zonker.net>]

On Mon, Nov 2, 2015, at 02:05 AM, Arvind Prabhakar wrote:
> Thanks for the explanation Joe. It seems like you are suggesting a
> process
> that you have seen work in the past and that is great. But every project
> is
> different and not every project community will adopt the same process.
> Hence I think this is not a valid ask.

Every "project" is not my concern. My concern is giving a thumbs up to a
project and saying "this is ready to be a self-governing and
self-perpetuating TLP at Apache where all people have a level playing
ground to contribute."

I don't see that with Sentry. The process currently seems
non-transparent to me, and non-friendly to people currently not in the
community. 

> If I extrapolate or read between the lines, I feel another issue being
> pointed out or which has been eluded to in the past is - who decides
> which
> Jiras should be fixed, what features to create etc, specially when they
> show up as Jira issues directly with patches that follow soon. It seems
> that in some ways the lack of using mailing lists directly for discussion
> is linked to this behavior of filing issues and fixing them rapidly, as
> if following a roadmap that the community does not have control over. Please
> pardon me if my interpretation/understanding of the issue is not right.
> But if it is right, then I do want to say that - that too is not an issue in
> my opinion at all. And here is why:

So, basically you're saying "yes, direction for Sentry is being guided
outside of Apache, but so what?" 

> When someone files a Jira, they are inviting the entire community to
> comment on it and provide feedback. If it is not in the interest of the
> project, I do believe that responsible members of the community will be
> quick to bring that out for discussion and even Veto it if necessary. If
> that is not happening, it is not an issue with lack of community
> participation, but rather it is an indicator of a project team that knows
> where the gaps are and understands how to go about filling them
> intuitively. I know this because I too have been on the side of a project
> much like Sentry - which was accused of not having a diverse community,
> lack of email communication, and overload of Jira issues, and possibly
> being guided by a silent hand that was not open to the community. Those
> were wrong and misplaced concerns, and the project has always behaved in
> the same way - even till today.

Who is this project team of which you speak? 

Sorry, but no - when someone files a Jira, they're inviting people
already involved in Sentry development to comment on it and provide
feedback. If you're saying "hey, if somebody files a Jira and someone
else objects, we'll listen" - that's great. 

If you're saying "this process is scalable and friendly to outsiders who
might want to become part of the Sentry community, who are outside the
current development team(s)," I strongly disagree. However, this is the
standard that Apache projects should be held to - not merely "existing
contributors/PMC members can provide feedback and object" but "newcomers
can follow development and become involved without unreasonable
barriers." 

> Going back to Sentry - I feel that the project team is desperately trying
> to mend their ways to accommodate mentor requests but I don't think they
> can, despite their best intentions. The whole idea of hangouts and calls
> for the community seems like an unnecessary attempt at building community
> when in fact they have a great community to begin with!  The project was
> functioning great as it was before, but our lack of appreciation for
> their process has led to these efforts which I don't think are helping at all.
> In fact these could be more damaging than before.

Basically, "we're happy with Sentry the way it was before it came to
Apache, why can't we be an Apache TLP without changing?!" 

I think it's fair to ask at this point why Sentry wants so badly to be
an Apache project? You're basically saying "we know how other Apache
projects work, but we don't want to do that." 

> Yes, we as mentors can guide them to a certain behavior but if what they
> are doing works for them, complies with the Apache Way, then who are we
> to question it?

My point is, I don't believe that it does comply with the Apache Way.
Sentry does not seem to be placing "community over code" in its
processes. 

Technical decisions are not being made publicly. You've pretty much
admitted as much here. 
 
We basically seem to be at an impasse. I can't in good conscience vote
+1 or even +0 for Sentry to graduate at this point. I think at this
point I'd like to open a discussion on general@ to see what other folks
in the IPMC think -- if I'm way off base, then you can hold a vote and
Sentry can graduate. But I'm now strongly -1 on Sentry graduating, and I
don't see any value in continuing to offer advice or assistance that is
unwanted.

Best,

jzb
-- 
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: Discussion at ApacheCon:BigData

[Arvind Prabhakar <ar...@apache.org>]

Thanks for the explanation Joe. It seems like you are suggesting a process
that you have seen work in the past and that is great. But every project is
different and not every project community will adopt the same process.
Hence I think this is not a valid ask.

I too feel that Mailing Lists are the life blood of communities and must be
utilized for all communication. However, where I respectfully disagree with
you (and perhaps with David) is that I don't think a direct email holds
more weight than a Jira notification. If I open a Jira and provide my
input/thoughts/and even a patch on it, it is the same to me as having an
open discussion and then taking it to Jira. It is just a different way of
communicating - wherein the Mailing List is the vehicle that connects all
interested parties in the community. I would argue that keeping the
technical discussion on the Jira is much better/cleaner than having it on
the mailing list - that is just my view, and something I have done in the
projects I have worked on.

If I extrapolate or read between the lines, I feel another issue being
pointed out or which has been eluded to in the past is - who decides which
Jiras should be fixed, what features to create etc, specially when they
show up as Jira issues directly with patches that follow soon. It seems
that in some ways the lack of using mailing lists directly for discussion
is linked to this behavior of filing issues and fixing them rapidly, as if
following a roadmap that the community does not have control over. Please
pardon me if my interpretation/understanding of the issue is not right. But
if it is right, then I do want to say that - that too is not an issue in my
opinion at all. And here is why:

When someone files a Jira, they are inviting the entire community to
comment on it and provide feedback. If it is not in the interest of the
project, I do believe that responsible members of the community will be
quick to bring that out for discussion and even Veto it if necessary. If
that is not happening, it is not an issue with lack of community
participation, but rather it is an indicator of a project team that knows
where the gaps are and understands how to go about filling them
intuitively. I know this because I too have been on the side of a project -
much like Sentry - which was accused of not having a diverse community,
lack of email communication, and overload of Jira issues, and possibly
being guided by a silent hand that was not open to the community. Those
were wrong and misplaced concerns, and the project has always behaved in
the same way - even till today.

Going back to Sentry - I feel that the project team is desperately trying
to mend their ways to accommodate mentor requests but I don't think they
can, despite their best intentions. The whole idea of hangouts and calls
for the community seems like an unnecessary attempt at building community
when in fact they have a great community to begin with!  The project was
functioning great as it was before, but our lack of appreciation for their
process has led to these efforts which I don't think are helping at all. In
fact these could be more damaging than before.

Yes, we as mentors can guide them to a certain behavior but if what they
are doing works for them, complies with the Apache Way, then who are we to
question it?

Last but not the least, I do agree that there were process mistakes made in
the past around release management. Those have since been taken care off by
the project team and addressed for subsequent releases. If that were a
gating criteria, I think they are good to go.

Regards,
Arvind Prabhakar









On Sun, Nov 1, 2015 at 7:13 PM, Joe Brockmeier <jz...@zonker.net> wrote:

> On Sat, Oct 31, 2015, at 04:59 PM, Lenni Kuff wrote:
> > Thanks for all the comments. Based on the previous feedback, we have
> > tried
> > to bring any offline discussions back to the dev list and have been using
> > the dev list as the forum for any decision making (as David pointed out).
> > In addition, Sravya has organized a regular monthly Google hangout [1] to
> > help facilitate discussions which may be easier to have face-to-face/over
> > the phone. The hangout will be open for anyone to join and all meeting
> > notes will be posted back the dev mailing list.
>
> "Have tried" is not the same as actually doing, nor am I comfortable at
> this stage saying "yes, as a mentor I feel this group has adopted best
> practices from Apache and is going to continue doing this on its own
> post-graduation."
>
> "Sravya has organized a regular monthly Google hangout" not quite.
> Sravya has sent out an email that appears to have gone directly to VOTE
> (no DISCUSS) for a 30-minute hangout.
>
> Note that this was about a week ago, and none of these hangouts have
> actually happened - so it's impossible to judge its effectiveness and
> describing it as "regular" at this point is a bit early.
>
> (As a side note, as much as I prefer discussions happen on a mailing
> list - if you're going to do a real-time conversation, I am not sure 30
> minutes is sufficient. At least in my experience, it usually takes ~5
> minutes for a distributed team to actually join a call and get started,
> and if you have any amount of discussion at all it would take some
> ruthless efficiency to get through a discussion *and* have time for an
> open floor for newcomers to ask questions.)
>
> > I apologize, but it's still bit unclear to me - based on the remaining
> > criteria you outlined - specifically what we still need to accomplish
> > before graduation.
>
> So - the discussion at ApacheCon happened, what, about a month ago? The
> types of things we're pointing out are not just checkboxes for the
> project to tick off, but fundamental practices we need to see in order
> to say "yes, this project is going to behave like an Apache project
> after graduation."
>
> Is Sentry producing code? Yes.
> Is Sentry producing releases? Yes.
> Is Sentry's infrastructure (Web site, Jira, mailing lists, and so on) in
> order? Yes.*
>
> All great!
>
> The tough one: Is Sentry creating an open and diverse community that
> allows anyone to participate? Right now, I don't think Sentry is there.
> What I see right now is a podling that has had a fair amount of
> communication about development out of the public eye and/or in channels
> that are difficult to join for the public at large.
>
> David and I have given feedback on steps Sentry can take to remedy this.
> What Sentry needs to accomplish now is to follow through on this and
> build a track record there. (See also [1])
>
> * Pretty sure. I did a quick cursory glance and things look good.
>
> [1] http://incubator.apache.org/guides/community.html#communication
>
> Best,
>
> jzb
> --
> Joe Brockmeier
> jzb@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
>