Wow a lot of information. Thanks for that. The points I wanted to bring up have already all been attended to, so I don't think reiterating is necessary. I will say that I'm a developper for a PHP driver so I count towards being a client user, yet have in the past been referred to as sort of a "vendor" so this is definitely more of a semantics issue in my mind.
Also, as a non-java driver developper I'm relaying the concerns and expectations of the community I serve. I suspect any driver developper or implementor goes through this as well, so although we may or may not have some sort of corporate affiliation it isn't always a fair assessment to say that the diversity of committers is limited to the number of individuals participating. I know this isn't news, and waves off legal concerns but there's no harm in reminding ourselves. As far as PMCs go I trust that the current team will grow it's diversity with time as the community grows. Implementing RTC would probably also help in the matter as promoting users with a strong java developing background may become less important than say, their involvement etc. etc. Best D On Mon, Oct 5, 2015 at 1:34 AM, Daniel Gruno <[email protected]> wrote: > On 10/05/2015 01:27 AM, Stephen Mallette wrote: > > 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). > > > > > I think (hope?!) Rich has been quoted out of context here. Decisions > about where the project is headed is NOT something you merely relay back > for a vote. You can discuss "how do I solve this specific bit of > functionality" or "how do I stop it from crashing >:(", sure - but > changing fundamental ways in which the program works NEEDS to be > discussed on the list. You can have informal discussions beforehand, > yes, but the decision-making discussion MUST be done on the list before > you start calling a vote. Examples of this are API-breaking changes, > minor/major version changes, new/updated roadmaps etc. > > With regards, > Daniel. >
