Ok, Rich is probably talking in the context you are describing Daniel - that brings the two positions in line in my mind -thanks.
I like what you wrote here: > 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. But aren't we doing that? If ALL of the work we do against for code is documented in JIRA, is that not sufficient place for discussion? The creation of a JIRA ticket is not saying, "I created this, therefore it must be done and it must be done for this version and in this timeframe." It's saying, "Here's an issue I believe should be worked on....feedback is welcome," Judging by the activity on the issues in JIRA, I'd say our community understands it as the latter. On Sun, Oct 4, 2015 at 7:34 PM, 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. >
