Wow, lots of stuff here - I'll just make a few points I think are important:
> getting influence because you are employed by a software vendor is problem I don't see where any particular "vendor" is getting special influence in TinkerPop. If you think you see that, then I think there continues to be a misunderstanding. To me, that's just a word that's not so different than "Powered By" which you see used in other Apache projects. If the word "vendors" continues to be misunderstood then let's make a concerted effort to eradicate it from TinkerPop usage. I tend to use the word "TinkerPop implementer", but there are other words out there that might be better. > Decision-making is happening elsewhere. Since our release of GA and the community decision to use JIRA to generate the CHANGELOG on release, I'd say virtually all dev discussion is happening via JIRA. Most all commits relate to a JIRA ticket in some way. I think we've made honest effort to get everything else on the dev list, which includes stuff like discussions on when to release, major design changes (i.e. the DISCUSS/VOTE to go to hadoop 2), and how to improve on our transparency (i.e. the discussion about using a public real-time chat). As an aside, I feel like we continue to get mixed messaging on what is allowed here. Daniel Gruno put it very specifically - you guys hate: > Foo and I discussed this and we wanna do this and that, please vote but then in our discussion to use a public chat for dev work, Rich wrote: > The "rule" is that decisions should be relayed back to the list, for the community to comment on. But off list discussion itself isn't a problem. Those two statements are not compatible in my mind. I have a feeling you are both right on the matter, but there's clearly some gray area we don't understand. It would be great if you could clarify this issue for us once and for all (especially if we end up going with this public chat route). Regarding: > such as the now complete lack of diversity in the project > (in terms of employers of committers/PMC) has gotten substantially worse. Let's set aside the PMC, which I think we can all admit lacks diversity. The committer pool however has been improving and I think we'll see more diversity there as we proceed toward the end of the year. In the end, I don't see how this can't be solved with more time. Mentors should have seen recent discussions on the "private" list for what "committership" should be - if the thinking was off-base then I would have thought that you would have let us know. I would imagine that as the committer pool grows the opportunity to expand the PMC will start to open up, but I imagine we have discussion ahead of us for that as well. Moving on to something else Daniel Gruno wrote: > If a RTC system is not adopted (or at least the laissez faire method is documented), we will enforce this on the PPMC. I can't speak as to why-or-why not RTC (review then commit, for those who might not have known)...it's never been discussed in full (I think Matt Frantz had mentioned it once as part of a thread on release branching). It wouldn't be hard to go to RTC now that we're more stable and doing work tied to JIRA. As the community is growing, I'd agree that we should have this discussion in full. All in all, I don't take a dismal outlook to the TinkerPop community proving it's ability to make the appropriate changes and eventually succeed in graduation. Most everything else for TinkerPop is quite healthy (releases, promotion, adoption, etc.), so with the same effort applied to those things, we can do the same for these issues that are troubling for graduation. On Sun, Oct 4, 2015 at 6:07 PM, Daniel Gruno <[email protected]> wrote: > [toooo much text, cropping it all out] > > There hasn't been made a 'decision' to kick out TinkerPop - where'd you > get that idea from, folks? David chatting to Rich and me in an informal > way as a mentor is not in any way an openness issue, he's making a > personal statement about what he believes is best for the project, it's > not a done deal or anything remotely close to that. > > Furthermore, you will have to accept that mentors discuss the project > off-the-record (as is done in all podlings!), much like potential new > committers are discussed on the private list - it may contain sensitive > information about the project or individuals that we don't want to shove > in peoples' faces, and it allows us to be very frank about matters. > > As for 'vendors', I would prefer to use a term similar to downstream > distributions/implementations, so as to not make it sound too corporate. > We are a 501c3 non-profit, and when you use terms like 'vendors', it > goes against the "for the public good" mission of the foundation (at > least as seen by certain people/govt branches) > > As for transparency, it irks us when we get yet-another-email saying > "Foo and I discussed this and we wanna do this and that, please vote", > or ESPECIALLY "I discussed committership with bar, and he/she has > accepted". > > First, a very specific rant: > > UNDER NO CIRCUMSTANCES ARE YOU TO EVER DISCUSS COMMITTERSHIP WITH A > POTENTIAL NEW COMMITTER PRIVATELY UNLESS A MENTOR SAYS IT'S OKAY. > You should only ever discuss this under special circumstances or after > (s)he has formally accepted the role. If we find out that people are > discussing such things without informing the mentors/PPMC first and > getting an ack, it is bordering on getting kicked out of the PPMC for > not following the rules. > > Then, a few more notes: > > - If you have any questions, please ask your mentors. We are here to > provide oversight, but we are generally not nearly as invested in the > project as you may be. We have, on average, 10+ other projects we also > have to deal with every day, plus our actual jobs, so keeping up with > the dev list alone is not an easy task. If you are in doubt or need > clarification on processes, please ask on the ML with [Mentors] or > similar tag added to the subject line, so we know you need assistance - > otherwise, it is to be expected that we might not read the email (I get > around 4,000 emails per day, just to put things into perspective). > > - Please have discussions before you start a vote. Votes are fine, but > if you go straight to a vote (as has happened), you take away peoples' > ability to say "what about option C?". > > - Mentors are generally reactive and descriptive, not proactive and > normative/prescriptive. Again, this is in part due to the amount of time > we have available to devote on the podling process, and also because > we'd like podlings to sort out their own mess. David's email should be > seen in this light. While I may not agree fully with the wording, I > agree with the sentiment that if TinkerPop is to survive and eventually > get a "ready to graduate" recommendation from the mentors, it needs to > _proove_ that to the mentors, and not just to themselves. We describe > and react to what we see, and if David sends a concerned letter like the > one he sent, it's because the project (or at least prominent PPMC > members) are doing/saying things that really irks him (and me as well). > I fully understand that you get defensive about your project, but I will > also note that you have only responded to the things you feel you can > defend, you have yet to react to the issues that might be more > 'embarrassing' to you, such as the now complete lack of diversity in the > project. I could go into details here, but I'll save you that bit of > tinfoil-hat-story. > > - On a more curious note: Why is the entire TinkerPop CTR and not RTC? > It strikes me as very odd that no code is ever voted upon, which is one > of the core tenants of the ASF, I just see commits straight to a release > candidate branch and then eventually a vote on the entire release, which > is NOT a veto-able vote. I will go as far as to say; If a RTC system is > not adopted (or at least the laissez faire method is documented), we > will enforce this on the PPMC. As seen from the outside, you do not have > a proper quality control of your code base, which makes me very > concerned about the quality of your releases. > > I could go on, but....beer and such. > > With regards, > Daniel. > > > PS: It might be a good idea for the mentors to post a monthly or > quarterly status update, so we can discuss our expectations and > impressions and see where we differ. >
