This discussion is cathartic for the project.
What follows is an attempt to summarize many of the excellent points to
build a list of "action items" for us. I did toss in some minimal
commentary...but this is mainly cut and paste summary of the major points I
saw. If something was left out, please add it.
1) "prefer big stuff be discussed on the mailing list" - this includes:
a) "project is headed" - Must be done on the mailing list.
My opinion: The mentors are absolutely right to identify this as a
problem with the project right now, in
my personal opinion.
b) Before any vote, there must be a discussion and enumeration of
voting choices on the mailing list.
c) Before depreciation of function or changes in technical direction,
there should be discussion on the mailing list.
MENTORS: Prioritization of work items, etc....mentors are correct - I
also saw a reference that this was done off line in a private conversation.
What is the recommended way to do this sort of work without flooding the
mailing list - which is not always the best vehicle to do the "horse
trading" needed to organize JIRA work ? Is announcing a Slack channel
discussion time / place or something else that anyone in the community can
join appropriate ? How do other projects do this ?
2) Do not use the "vendor" word.....
"driver developer" was suggested. "application developers" was
suggested. That covers
both sides of TinkerPop. I am afraid I'll be the first to blow it
here and use "vendor" again....
We just need a common language where we don't get confused.
3) Interest in Other Apache Projects
It is hard to expand on Jason's extensive list of Apache integrations
that exist with TinkerPop -
Apache Spark
Apache Giraph
Apache Cassandra
Apache HBase w(ith Titan included)
Apache Falcon
Apache Atlas
Apachecon talks
Discussion with the Flink Team, And thoughts around GraphX on Spark.
However...the *perception* is important, and there is perception that
we are not a good Apache community player...so ...work to do to further
understand and correct this perception.
To inject personal opinion in what is supposed to be a recap of points
already made...I do believe the TinkerPop project could do a better job
focusing on adoption of new releases and enablement prior to rushing off to
the next new thing. Yes, it means we might move a bit slower. Could we
help the Flink project, or be more aggressive integrating with the Spark
team ? Good conversation for the mailing list and our mentors to see if
this is what they mean and if this is what we want to do.
4) Implementing RTC
If this adds more transparency requested by the mentors, then what do
we think ?
5) UNDER NO CIRCUMSTANCES ARE YOU TO EVER DISCUSS COMMITTERSHIP WITH A
POTENTIAL NEW COMMITTER PRIVATELY UNLESS A MENTOR SAYS IT'S OKAY.
Yeah. OK. I think the all caps says it all...we'll just do this one
;-) I am not even a committer, just a tormentor.
6) ....mentors to post a monthly or quarterly status update
Yes, great idea. Keeps the two way channel open.
MENTORS: Is it David or Daniel who we can expect to do this for us to
keep the dialog going ?
And should we expect it monthly or quarterly ?
On Mon, Oct 5, 2015 at 8:02 AM, Stephen Mallette <[email protected]>
wrote:
> I don't think it's necessary to pull out specific instances. Ultimately,
> the perception of mentors is that there is significant decision-making
> activity happening elsewhere. Perhaps the thinking that it was
> "significant" was partially because the activity in JIRA wasn't
> known/considered. I hope that in this revised light, we can reduce the
> emphasis on "significant" in your minds.
>
> I agree that it might be hard to follow JIRA when not attached to the
> project day-in/out. David Robinson had mentioned such a thing at one point
> in one of the dev threads. I can see how that might affect our ability to
> get people easily engaged in the discussion, but it is good to be clear
> that decision-making in that forum is not in and of itself wrong to do and
> that mentors are now aware of our usage of it in this fashion.
>
>
> On Mon, Oct 5, 2015 at 7:03 AM, Daniel Gruno <[email protected]> wrote:
>
> > On 10/05/2015 01:00 PM, Stephen Mallette wrote:
> > > 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.
> > >
> >
> > If all major decisions are made through a system that allows for
> > provenance, that is fine - I would prefer the big stuff be discussed on
> > the mailing list (and not inside JIRA), so other people can join in.
> > Discussing everything in JIRA makes it hard to follow, as a lot of
> > people tune out JIRA messages by default.
> >
> > However, the impression we sometimes get is that some decisions are made
> > via skype or other non-ASF channels, and then brought to the ML for a
> > vote or notification, and that part is NOT okay.
> >
> > I can find examples of this if need be, but I'm sure you can find them
> > yourself as well.
> >
> > With regards,
> > Daniel.
> >
>
