Thanks for the feedback everyone. It seems like the only follow up points I have heard thus far are around the Committer == PMC model. I will split that off as a separate discussion thread on its own. Feel free to follow up on this thread if there is additional feedback, unrelated to that topic.
Thanks, Lenni On Thu, Dec 3, 2015 at 10:27 AM, Patrick Hunt <[email protected]> wrote: > As I stated (hopefully clearly) on the recent general@ list I believe this > podling is ready to graduate. I don't feel I have much to add at this > point. > > Patrick > > On Fri, Nov 27, 2015 at 12:41 PM, Sravya Tirukkovalur <[email protected] > > > wrote: > > > On Sun, Nov 22, 2015 at 10:28 PM, Arvind Prabhakar <[email protected]> > > wrote: > > > > > The key concern that triggered the Sentry graduation mega-thread and > its > > > offshoots was that decisions were being made outside of mailing list > by a > > > select few people in the hallways. That concern was put to rest by > > > clarification of how Sentry has been using JIRA as a primary means of > > > discussion. From a graduation perspective, I feel this issue is > resolved. > > > > > > The issue about RTC/CTR is for the project to decide and as long as > code > > is > > > getting committed, contributions are welcome from all, and releases are > > > being made - that too is not a issue from graduation perspective. > > > > > > IMO, this is a non issue for Sentry as current approach is working out > > very well, and I do not see a reason changing it. > > > > > > > The use of maturity model is a good thing to turn a subjective read > into > > a > > > measurable/objective score and is a great idea, but as has been > > established > > > in the discussions, not a requirement for graduation. > > > > > > I agree this is a non issue for the graduation, but some thing which > > helps > > in getting a perspective on path to graduation especially for the folks > who > > are not involved in the community on a day to day basis. Any volunteers > to > > take a stab at it? > > > > Which leaves us to the final issue which is truly concerning - the lack > of > > > new PPMC members. I took the time to go through the history of all PPMC > > > conversations on the private list to see if there was any systemic > issue > > > stopping the inclusion of new PPMC members. What I found however was > > quite > > > to the contrary - that all the PPMC discussions have mostly been around > > > getting new committers in or creating board reports. The one time that > > the > > > PPMC did talk about changing a policy - it cited a thread that was > > already > > > voted on by the dev list [1]. This implies to me that the PPMC has > driven > > > project direction by broader consensus, and thus effectively empowered > > all > > > committers and even contributors to guide it's direction already. > Hence, > > > for Sentry moving to the model where Committer == PPMC is the right > thing > > > for the project, and is perhaps happening implicitly already. By making > > > this explicit, these new committers will be able to participate in the > > > committer votes which will greatly benefit the project further. > > > > > > +1 here. I agree we should formally promote folks to PPMC, although we > > implicitly have all long time contributors(committers) participating in > > most of the PMC responsibilities[1]. Would love to hear thoughts from > > others here, especially around reasons why PPMC = Committer worked out > well > > (or not?) in other podlings. And also thoughts on making all committers > > PPMCs at the time of graduation. > > > > Last but not least - I am aware that not all mentors of the project think > > > alike. Hence I don't want to make any representation on behalf of other > > > mentors but would strongly encourage them to participate in this thread > > and > > > share their views in case they disagree with any of my assessments > above. > > > > > > [1] http://s.apache.org/nyp > > > > > > Regards, > > > Arvind Prabhakar > > > > > > [1]: http://www.apache.org/foundation/how-it-works.html#pmc-members > > > > Regards, > > > > On Sat, Nov 21, 2015 at 3:08 AM, Lenni Kuff <[email protected]> wrote: > > > > > > > Thanks for summarizing things Sravya. > > > > > > > > On Tue, Nov 17, 2015 at 11:56 AM, Sravya Tirukkovalur < > > > [email protected] > > > > > > > > > wrote: > > > > > > > > > Hi Sentry community, > > > > > > > > > > We have had discussions about Sentry on general@ as well as dev@ > > > around > > > > > its > > > > > readiness to graduate and current project workflows. It was good to > > see > > > > > many folks on IPMC chiming in the discussion (~150 long thread). > > There > > > > are > > > > > multiple discussions happening on that thread [1] , including more > > > > general > > > > > discussions about the state of the Incubator. I want to summarize > > some > > > of > > > > > the topics discussed so we can discuss how these relate to Sentry. > > > Would > > > > > also like to hear from the mentors if there is anything I missed > > here: > > > > > > > > > > 1. Importance of PPMC growth - should committer == PMC? > > > > > > > > > > > > > Agree that building a successful community involves both growing > > > committers > > > > as well as growing the PPMC. We should consider how we can encourage > > > > community growth at both the committer and PMC level. One topic > brought > > > up > > > > in the general@ thread was around the distinction between Committer > > and > > > > PMC > > > > member. Sentry currently treats committer != PPMC. However, there are > > > many > > > > other projects that treat committer == PPMC while in incubation. It's > > > been > > > > two years since the project started and we have many new community > > > members > > > > - it would be good to revisit whether our initial model is still what > > > makes > > > > sense. Perhaps we should move to a Committer == PPMC model? This can > > > > probably be spun off into its own discussion thread, interested to > hear > > > > other people's thoughts. > > > > > > > > > > > > > > > > > 2. Balance of discussions on Jira versus email > > > > > > > > > > > > > This was interesting. For Sentry, we have been having lots of good > > > > discussions on JIRA and Review Board. This seems to have worked well. > > One > > > > thing I think we should really encourage is for design discussions, > > > roadmap > > > > discussions, etc all be held on the dev list rather than on JIRA. If > > you > > > > are solving a hard problem leverage the community to get input. > > > > > > > > > > > > > 3. CTR (Commit then Review) versus RTC (Review then commit) > > > > > > > > > > > > > There is a great discussion continuing on this topic on general@ > right > > > > now. > > > > I'm think it is very project dependent. If you are interested I > > encourage > > > > taking a look and jumping in to this thread: > > > > > > > > > > > > > > http://mail-archives.apache.org/mod_mbox/incubator-general/201511.mbox/%3CCADY20s7VZzHA2BVN7oERHFA6AfeCeKj3MMtLb%2BNv-HX6uyvhkw%40mail.gmail.com%3E > > > > > > > > > > > > > > > > > 4. Should podlings fill the maturity model template. > > > > > > > > > > > > > IMO, this seems like a useful thing to go through prior to > graduation. > > It > > > > seems like it has some good topics to think through and see how those > > > apply > > > > to Sentry. I'm not in favor of having all graduating project fill > this > > > out, > > > > but given the healthy discussion that has been going on around Sentry > > > > (including some misconceptions) maybe we should do this. > > > > > > > > > > > > > > > > > > It would be good to start discussing these within our community to > > get > > > > > every ones thoughts on these topics and if we want to consider any > > > > changes > > > > > based on all the input we received. Ultimately, it's up to the > > > community > > > > to > > > > > decide what works best for them. > > > > > > > > > > [1]: > > > > > > > > > > > > > > > > > > > > http://mail-archives.apache.org/mod_mbox/incubator-general/201511.mbox/%3C1446465555.3149570.426574697.76AAA52B%40webmail.messagingengine.com%3E > > > > > > > > > > Regards, > > > > > -- > > > > > Sravya Tirukkovalur > > > > > > > > > > > > > > > > > > > > -- > > Sravya Tirukkovalur > > >
