On Mon, Oct 5, 2015 at 1:27 AM, Stephen Mallette <[email protected]> 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). >
There's much gray area, and there are varying degrees of this. It's a hard concept to convey adequately, so let me try some examples. Generally bad: 2 or more folks go off in private, iterate on an idea, perhaps even end up with some code, and then when it's ready to be consumed, expose the idea and the code for acceptance all at once. Effectively this is deciding externally and offering an ultimatum to the project. Less bad, but still far from ideal: 2 or more folks discuss a problem and decide upon a solution. This discussion is then brought to the list and the project is asked to decide to move forward or not; effectively forcing a boolean answer. This can squash dialogue, particularly in the case of folks with lots of stature in the community; folks, especially nascent community members are unlikely to offer alternative suggestions or even get involved in the discussion. This isn't quite an ultimatum, but it can be exclusionary. Not bad, though not ideal either: 2 or more folks have a conversation about a problem/new feature/$whatever. Without espousing or deciding on a course of action, they carry that to the list. Maybe they even offer a few potential solutions, and ask for feedback, thoughts, etc. This is better than having decided on a solution, but it's still less than ideal, because there was a private meeting that others were excluded from. The reality is that this can't really be avoided, you're going to have opportunities to sit down in person with folks, you'll have phone calls, you may even be located in the same office. The key is to be mindful of the effect. Try and ensure that it is not the primary method that things happen. Also realize that for new community members, it can seem like there is a cabal. This perception is doubly sinister if there appears to be a primary employer of a majority of contributors, or the folks in the conversation all share the same employer. That often breeds distrust of motives, even if it's completely innocuous. Better: The community has a 'place' (IRC, Slack, Hipchat, G+ Hangouts) and a time that is regularly announced. This allows anyone who wants to participate or observe to show up. Minutes are kept of the meeting (either chat log or someone taking notes) and timely shared back with the project. Most importantly, decisions still aren't made in this venue. Proposals might be made, but those need to come back to the mailing list. This still isn't perfect though. Some people who may want to participate may have time zone skew, may have other life obligations during the scheduled time. The reality is that there is no ideal time for a globally distributed project. Best: Ideas, problems, proposals are discussed early, primarily on the list (or Jira, or in PR, though all of those have a higher barrier to participation for new folks) with feedback solicited. There's no rush to solution, folks, even if they are on the opposite side of the world, will have an opportunity to weigh in before a decision is made. This isn't the fastest, or the most efficient in terms of churning out code, but it does help foster community growth. --David
