The future of Tinkerpop

[David Nalley <da...@gnsa.us>]

Hi folks,

A number of the mentors (Daniel, Rich, and I), along with several
other IPMC members were in Budapest for ApacheCon; while there we
discussed the state of
Tinkerpop, it's incubation, and a number of other topics. I wanted to
bring one of those topics here to foster a larger discussion, and
perhaps for the community to decide on a way forward.

After a lot of deliberation and thinking both together and
individually, I think we reached an inflection point for ourselves.
While I don't want to speak for the others,
I will state my opinion. I think it's become apparent that Tinkerpop
as a project and a community is not a fit for the Apache Software
Foundation, and I see little potential for that to change.
This is not a statement that Tinkerpop is bad or evil. The ASF isn't
the only place projects live to be successful, nor is the Apache Way
the only method that successful projects adopt.

That said, the ASF cares deeply about it's existing culture and that
the communities that are here adopt "the Apache Way"; that's actually
a core tenant to accomplish during incubation. That leads
me (speaking only for myself) to believe that you would thrive better
elsewhere, rather than chafing and being unhappy, and eventually
failing to graduate.

--David

Re: The future of Tinkerpop

[David Robinson <dr...@gmail.com>]

Hi David,

As a TinkerPop community member, I appreciate the time and effort you
contribute
to our project and to the Apache Foundation, understanding that there are a
lot of
volunteer hours contributed.

However, agreeing with the others who have responded, I am surprised at how
pessimistic your assessment of the community and the overall project are.

I thought one function of Incubation was to provide the opportunity for a
community
to learn and grow in the Apache Way.  Looking at the dimensions listed below
from the Apache Way description, can you articulate in what ways socially
or technically we are falling short in each area  so that we can discuss
and make attempts, if necessary, at addressing your's and other's concerns ?


   - collaborative software development
   -

   commercial-friendly standard license
   -

   consistently high quality software
   -

   respectful, honest, technical-based interaction
   -

   faithful implementation of standards
   -

   security as a mandatory feature

http://apache.org/foundation/how-it-works.html

Thanks,

On Fri, Oct 2, 2015 at 3:09 PM, Jason Plurad <pl...@gmail.com> wrote:

> If there are specific points in the Apache Way where TinkerPop is failing,
> let's get those listed out publicly on the dev list. That is step #1 in
> order to get them addressed. I'd also want to learn more about how the
> mentors have been teaching and leading the process since January. I wish
> such a provocative post would have had more context around it from the
> mentor perspective.
>
> I was fortunate enough to have a chance to meet with almost all of the
> TinkerPop committers (and many Cassandra committers) last week at the
> Cassandra Summit. I asked how they felt about being in Apache, and other
> than the long delays on voting, they seemed pretty excited to be on board.
>
>
>
> On Fri, Oct 2, 2015 at 1:42 PM, Matthias Broecheler <me...@matthiasb.com>
> wrote:
>
> > +1
> > Not being intimately involved with the Apache foundation and its
> processes,
> > this conclusion comes out of the blue for me and it would be hugely
> > valuable to understand the reasoning behind it.
> > Being a consumer of Tinkerpop and not a committer, I have been quite
> > impressed with the rapid rate of innovation that the project exhibited
> > while growing the community.
> >
> > Thanks,
> > Matthias
> >
> > On Fri, Oct 2, 2015, 11:42 AM Matt Frantz <ma...@gmail.com>
> > wrote:
> >
> > > As Dylan suggests, I'd appreciate more details on "the Apache Way" and
> > why,
> > > specifically, TinkerPop has not aligned thus far.  This is my first
> > > experience at incubation, so any examples of successful incubations and
> > how
> > > they differ from TinkerPop would seem to be relevant.
> > >
> > > Regards,
> > > Matt
> > >
> > > On Fri, Oct 2, 2015 at 7:33 AM, Dylan Millikin <
> dylan.millikin@gmail.com
> > >
> > > wrote:
> > >
> > > > I know there was a very long discussion around this posted a while
> back
> > > but
> > > > maybe it would be good to break that down here for those of us that
> > > haven't
> > > > had the time to go through the entire thing (e.g. why you reached
> that
> > > > conclusion).
> > > >
> > > > This would certainly make the dialogue easier.
> > > >
> > > > Best,
> > > > Dylan.
> > > >
> > > > On Fri, Oct 2, 2015 at 3:15 PM, Rich Bowen <rb...@rcbowen.com>
> wrote:
> > > >
> > > > > On Oct 2, 2015 3:08 PM, "David Nalley" <da...@gnsa.us> wrote:
> > > > > >
> > > > > > Hi folks,
> > > > > >
> > > > > > A number of the mentors (Daniel, Rich, and I), along with several
> > > > > > other IPMC members were in Budapest for ApacheCon; while there we
> > > > > > discussed the state of
> > > > > > Tinkerpop, it's incubation, and a number of other topics. I
> wanted
> > to
> > > > > > bring one of those topics here to foster a larger discussion, and
> > > > > > perhaps for the community to decide on a way forward.
> > > > > >
> > > > > > After a lot of deliberation and thinking both together and
> > > > > > individually, I think we reached an inflection point for
> ourselves.
> > > > > > While I don't want to speak for the others,
> > > > > > I will state my opinion. I think it's become apparent that
> > Tinkerpop
> > > > > > as a project and a community is not a fit for the Apache Software
> > > > > > Foundation, and I see little potential for that to change.
> > > > > > This is not a statement that Tinkerpop is bad or evil. The ASF
> > isn't
> > > > > > the only place projects live to be successful, nor is the Apache
> > Way
> > > > > > the only method that successful projects adopt.
> > > > > >
> > > > > > That said, the ASF cares deeply about it's existing culture and
> > that
> > > > > > the communities that are here adopt "the Apache Way"; that's
> > actually
> > > > > > a core tenant to accomplish during incubation. That leads
> > > > > > me (speaking only for myself) to believe that you would thrive
> > better
> > > > > > elsewhere, rather than chafing and being unhappy, and eventually
> > > > > > failing to graduate.
> > > > > >
> > > > > > --David
> > > > >
> > > > > David expresses this as just his own opinion, but we did discuss
> and
> > > > draft
> > > > > this together. I want to reiterate that we think you have an
> amazing
> > > > > project and a great community, but that the fit doesn't seem to be
> > > there.
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Have a good one,
> Jason
>

Re: The future of Tinkerpop

[Jason Plurad <pl...@gmail.com>]

If there are specific points in the Apache Way where TinkerPop is failing,
let's get those listed out publicly on the dev list. That is step #1 in
order to get them addressed. I'd also want to learn more about how the
mentors have been teaching and leading the process since January. I wish
such a provocative post would have had more context around it from the
mentor perspective.

I was fortunate enough to have a chance to meet with almost all of the
TinkerPop committers (and many Cassandra committers) last week at the
Cassandra Summit. I asked how they felt about being in Apache, and other
than the long delays on voting, they seemed pretty excited to be on board.



On Fri, Oct 2, 2015 at 1:42 PM, Matthias Broecheler <me...@matthiasb.com>
wrote:

> +1
> Not being intimately involved with the Apache foundation and its processes,
> this conclusion comes out of the blue for me and it would be hugely
> valuable to understand the reasoning behind it.
> Being a consumer of Tinkerpop and not a committer, I have been quite
> impressed with the rapid rate of innovation that the project exhibited
> while growing the community.
>
> Thanks,
> Matthias
>
> On Fri, Oct 2, 2015, 11:42 AM Matt Frantz <ma...@gmail.com>
> wrote:
>
> > As Dylan suggests, I'd appreciate more details on "the Apache Way" and
> why,
> > specifically, TinkerPop has not aligned thus far.  This is my first
> > experience at incubation, so any examples of successful incubations and
> how
> > they differ from TinkerPop would seem to be relevant.
> >
> > Regards,
> > Matt
> >
> > On Fri, Oct 2, 2015 at 7:33 AM, Dylan Millikin <dylan.millikin@gmail.com
> >
> > wrote:
> >
> > > I know there was a very long discussion around this posted a while back
> > but
> > > maybe it would be good to break that down here for those of us that
> > haven't
> > > had the time to go through the entire thing (e.g. why you reached that
> > > conclusion).
> > >
> > > This would certainly make the dialogue easier.
> > >
> > > Best,
> > > Dylan.
> > >
> > > On Fri, Oct 2, 2015 at 3:15 PM, Rich Bowen <rb...@rcbowen.com> wrote:
> > >
> > > > On Oct 2, 2015 3:08 PM, "David Nalley" <da...@gnsa.us> wrote:
> > > > >
> > > > > Hi folks,
> > > > >
> > > > > A number of the mentors (Daniel, Rich, and I), along with several
> > > > > other IPMC members were in Budapest for ApacheCon; while there we
> > > > > discussed the state of
> > > > > Tinkerpop, it's incubation, and a number of other topics. I wanted
> to
> > > > > bring one of those topics here to foster a larger discussion, and
> > > > > perhaps for the community to decide on a way forward.
> > > > >
> > > > > After a lot of deliberation and thinking both together and
> > > > > individually, I think we reached an inflection point for ourselves.
> > > > > While I don't want to speak for the others,
> > > > > I will state my opinion. I think it's become apparent that
> Tinkerpop
> > > > > as a project and a community is not a fit for the Apache Software
> > > > > Foundation, and I see little potential for that to change.
> > > > > This is not a statement that Tinkerpop is bad or evil. The ASF
> isn't
> > > > > the only place projects live to be successful, nor is the Apache
> Way
> > > > > the only method that successful projects adopt.
> > > > >
> > > > > That said, the ASF cares deeply about it's existing culture and
> that
> > > > > the communities that are here adopt "the Apache Way"; that's
> actually
> > > > > a core tenant to accomplish during incubation. That leads
> > > > > me (speaking only for myself) to believe that you would thrive
> better
> > > > > elsewhere, rather than chafing and being unhappy, and eventually
> > > > > failing to graduate.
> > > > >
> > > > > --David
> > > >
> > > > David expresses this as just his own opinion, but we did discuss and
> > > draft
> > > > this together. I want to reiterate that we think you have an amazing
> > > > project and a great community, but that the fit doesn't seem to be
> > there.
> > > >
> > >
> >
>



-- 
Have a good one,
Jason

Re: The future of Tinkerpop

[Matthias Broecheler <me...@matthiasb.com>]

+1
Not being intimately involved with the Apache foundation and its processes,
this conclusion comes out of the blue for me and it would be hugely
valuable to understand the reasoning behind it.
Being a consumer of Tinkerpop and not a committer, I have been quite
impressed with the rapid rate of innovation that the project exhibited
while growing the community.

Thanks,
Matthias

On Fri, Oct 2, 2015, 11:42 AM Matt Frantz <ma...@gmail.com>
wrote:

> As Dylan suggests, I'd appreciate more details on "the Apache Way" and why,
> specifically, TinkerPop has not aligned thus far.  This is my first
> experience at incubation, so any examples of successful incubations and how
> they differ from TinkerPop would seem to be relevant.
>
> Regards,
> Matt
>
> On Fri, Oct 2, 2015 at 7:33 AM, Dylan Millikin <dy...@gmail.com>
> wrote:
>
> > I know there was a very long discussion around this posted a while back
> but
> > maybe it would be good to break that down here for those of us that
> haven't
> > had the time to go through the entire thing (e.g. why you reached that
> > conclusion).
> >
> > This would certainly make the dialogue easier.
> >
> > Best,
> > Dylan.
> >
> > On Fri, Oct 2, 2015 at 3:15 PM, Rich Bowen <rb...@rcbowen.com> wrote:
> >
> > > On Oct 2, 2015 3:08 PM, "David Nalley" <da...@gnsa.us> wrote:
> > > >
> > > > Hi folks,
> > > >
> > > > A number of the mentors (Daniel, Rich, and I), along with several
> > > > other IPMC members were in Budapest for ApacheCon; while there we
> > > > discussed the state of
> > > > Tinkerpop, it's incubation, and a number of other topics. I wanted to
> > > > bring one of those topics here to foster a larger discussion, and
> > > > perhaps for the community to decide on a way forward.
> > > >
> > > > After a lot of deliberation and thinking both together and
> > > > individually, I think we reached an inflection point for ourselves.
> > > > While I don't want to speak for the others,
> > > > I will state my opinion. I think it's become apparent that Tinkerpop
> > > > as a project and a community is not a fit for the Apache Software
> > > > Foundation, and I see little potential for that to change.
> > > > This is not a statement that Tinkerpop is bad or evil. The ASF isn't
> > > > the only place projects live to be successful, nor is the Apache Way
> > > > the only method that successful projects adopt.
> > > >
> > > > That said, the ASF cares deeply about it's existing culture and that
> > > > the communities that are here adopt "the Apache Way"; that's actually
> > > > a core tenant to accomplish during incubation. That leads
> > > > me (speaking only for myself) to believe that you would thrive better
> > > > elsewhere, rather than chafing and being unhappy, and eventually
> > > > failing to graduate.
> > > >
> > > > --David
> > >
> > > David expresses this as just his own opinion, but we did discuss and
> > draft
> > > this together. I want to reiterate that we think you have an amazing
> > > project and a great community, but that the fit doesn't seem to be
> there.
> > >
> >
>

Re: The future of Tinkerpop

[Matt Frantz <ma...@gmail.com>]

As Dylan suggests, I'd appreciate more details on "the Apache Way" and why,
specifically, TinkerPop has not aligned thus far.  This is my first
experience at incubation, so any examples of successful incubations and how
they differ from TinkerPop would seem to be relevant.

Regards,
Matt

On Fri, Oct 2, 2015 at 7:33 AM, Dylan Millikin <dy...@gmail.com>
wrote:

> I know there was a very long discussion around this posted a while back but
> maybe it would be good to break that down here for those of us that haven't
> had the time to go through the entire thing (e.g. why you reached that
> conclusion).
>
> This would certainly make the dialogue easier.
>
> Best,
> Dylan.
>
> On Fri, Oct 2, 2015 at 3:15 PM, Rich Bowen <rb...@rcbowen.com> wrote:
>
> > On Oct 2, 2015 3:08 PM, "David Nalley" <da...@gnsa.us> wrote:
> > >
> > > Hi folks,
> > >
> > > A number of the mentors (Daniel, Rich, and I), along with several
> > > other IPMC members were in Budapest for ApacheCon; while there we
> > > discussed the state of
> > > Tinkerpop, it's incubation, and a number of other topics. I wanted to
> > > bring one of those topics here to foster a larger discussion, and
> > > perhaps for the community to decide on a way forward.
> > >
> > > After a lot of deliberation and thinking both together and
> > > individually, I think we reached an inflection point for ourselves.
> > > While I don't want to speak for the others,
> > > I will state my opinion. I think it's become apparent that Tinkerpop
> > > as a project and a community is not a fit for the Apache Software
> > > Foundation, and I see little potential for that to change.
> > > This is not a statement that Tinkerpop is bad or evil. The ASF isn't
> > > the only place projects live to be successful, nor is the Apache Way
> > > the only method that successful projects adopt.
> > >
> > > That said, the ASF cares deeply about it's existing culture and that
> > > the communities that are here adopt "the Apache Way"; that's actually
> > > a core tenant to accomplish during incubation. That leads
> > > me (speaking only for myself) to believe that you would thrive better
> > > elsewhere, rather than chafing and being unhappy, and eventually
> > > failing to graduate.
> > >
> > > --David
> >
> > David expresses this as just his own opinion, but we did discuss and
> draft
> > this together. I want to reiterate that we think you have an amazing
> > project and a great community, but that the fit doesn't seem to be there.
> >
>

Re: The future of Tinkerpop

[Dylan Millikin <dy...@gmail.com>]

I know there was a very long discussion around this posted a while back but
maybe it would be good to break that down here for those of us that haven't
had the time to go through the entire thing (e.g. why you reached that
conclusion).

This would certainly make the dialogue easier.

Best,
Dylan.

On Fri, Oct 2, 2015 at 3:15 PM, Rich Bowen <rb...@rcbowen.com> wrote:

> On Oct 2, 2015 3:08 PM, "David Nalley" <da...@gnsa.us> wrote:
> >
> > Hi folks,
> >
> > A number of the mentors (Daniel, Rich, and I), along with several
> > other IPMC members were in Budapest for ApacheCon; while there we
> > discussed the state of
> > Tinkerpop, it's incubation, and a number of other topics. I wanted to
> > bring one of those topics here to foster a larger discussion, and
> > perhaps for the community to decide on a way forward.
> >
> > After a lot of deliberation and thinking both together and
> > individually, I think we reached an inflection point for ourselves.
> > While I don't want to speak for the others,
> > I will state my opinion. I think it's become apparent that Tinkerpop
> > as a project and a community is not a fit for the Apache Software
> > Foundation, and I see little potential for that to change.
> > This is not a statement that Tinkerpop is bad or evil. The ASF isn't
> > the only place projects live to be successful, nor is the Apache Way
> > the only method that successful projects adopt.
> >
> > That said, the ASF cares deeply about it's existing culture and that
> > the communities that are here adopt "the Apache Way"; that's actually
> > a core tenant to accomplish during incubation. That leads
> > me (speaking only for myself) to believe that you would thrive better
> > elsewhere, rather than chafing and being unhappy, and eventually
> > failing to graduate.
> >
> > --David
>
> David expresses this as just his own opinion, but we did discuss and draft
> this together. I want to reiterate that we think you have an amazing
> project and a great community, but that the fit doesn't seem to be there.
>

Re: The future of Tinkerpop

[Rich Bowen <rb...@rcbowen.com>]

On Oct 2, 2015 3:08 PM, "David Nalley" <da...@gnsa.us> wrote:
>
> Hi folks,
>
> A number of the mentors (Daniel, Rich, and I), along with several
> other IPMC members were in Budapest for ApacheCon; while there we
> discussed the state of
> Tinkerpop, it's incubation, and a number of other topics. I wanted to
> bring one of those topics here to foster a larger discussion, and
> perhaps for the community to decide on a way forward.
>
> After a lot of deliberation and thinking both together and
> individually, I think we reached an inflection point for ourselves.
> While I don't want to speak for the others,
> I will state my opinion. I think it's become apparent that Tinkerpop
> as a project and a community is not a fit for the Apache Software
> Foundation, and I see little potential for that to change.
> This is not a statement that Tinkerpop is bad or evil. The ASF isn't
> the only place projects live to be successful, nor is the Apache Way
> the only method that successful projects adopt.
>
> That said, the ASF cares deeply about it's existing culture and that
> the communities that are here adopt "the Apache Way"; that's actually
> a core tenant to accomplish during incubation. That leads
> me (speaking only for myself) to believe that you would thrive better
> elsewhere, rather than chafing and being unhappy, and eventually
> failing to graduate.
>
> --David

David expresses this as just his own opinion, but we did discuss and draft
this together. I want to reiterate that we think you have an amazing
project and a great community, but that the fit doesn't seem to be there.

Re: The future of Tinkerpop

[Marko Rodriguez <ok...@gmail.com>]

Hello,

The reason for silence from me (in particular) was to demonstrate a flaw in Dave's argument. He was trying to reprimand an individual (or two) but he inadvertently jumped the hierarchy and talked in terms of TinkerPop as a whole. Thus, there was a lack of precision to his presentation which was further enforced by the fact the individual(s) he was trying to get at did not reply. Why did they not reply? Because they didn't need to as it wasn't addressed to them, but the community. As such, the best defense is to have the community reply as their responses were as one would expect: 

	* "What are you talking bout?"
	* "Can you please explain yourself in more detail?"
	* … and the like.

This seemed to have left Dave in a pickle. Where does he go from there? What saved the situation, I believe, was Mr. Gruno with his remarks to particulars and what I think has ultimately remedied the situation -- Apache HipChat! Once we had a room set up where everyone could talk, ask questions, etc., then it all didn't seem as dire as originally proposed. Communication is key and fast back-and-forths with Gruno helped illuminate the best steps forward.

	* "Oh, you mean just bring up juicy JIRA ideas on the mailing list with [DISCUSS]? Sure."
	* "Oh, set up a merge to master process. Okay."
	* "Yes, makes sense... thank you for your help."

Next, to your recommendation about pulling people into the PMC that have simply replied to Dave's email (though not belittling with "simply" as their arguments were brilliant and well written). My view on the matter is as follows. Here is what I (me personally) think makes a project lead (in rank order):

	1. Consistent dedication to the project -- both in daily time and effort over the years (where the latter will have to rely on prediction).
	2. A deep understanding of the graph community -- the providers, the languages, the players.
	3. A deep understanding of the graph technology -- the theory, the algorithms, the future.
	4. Consistently promoting TinkerPop through collaborations, academic writing, blog posts, provider engagement, conference presentations, books, etc.
	5. An ability to attract talent and grow TinkerPop, not with "people," but with "artisans" (individuals who love the craft and dedicate themselves to it wholeheartedly).
	6. The ability to communicate effectively and work situations in TinkerPop's favor.

Does an individual have to have all 6? No, but writing "an email" is only one of those --- #6. The PMC is definitely conscious of the requirement to diversify the PMC for graduation. Though, one must not act hasty in such matters. If graduation is the goal, then TinkerPop has failed. The goal (for me personally) is a successful open source project that leads the graph space into the future with or without Apache. If we rush to graduate by being artificial in our behaviors and insincere in our approach that will yield the destruction of our prolificness and the ultimate joy we get from the love given to us by The TinkerPop.

Thanks,
Marko.

http://markorodriguez.com

On Oct 10, 2015, at 5:30 AM, Rich Bowen <rb...@rcbowen.com> wrote:

> There's been some good discussion here. I'd like to make an observation - most of the best "let's fix this" discussion has come from people who are not on the PMC, while the PMC members have been largely silent.
> 
> This seems important to me. I would suggest that it indicates that there are a number of people who should be on the PMC who are not yet.
> 
> On 10/02/2015 09:08 AM, David Nalley wrote:
>> Hi folks,
>> 
>> A number of the mentors (Daniel, Rich, and I), along with several
>> other IPMC members were in Budapest for ApacheCon; while there we
>> discussed the state of
>> Tinkerpop, it's incubation, and a number of other topics. I wanted to
>> bring one of those topics here to foster a larger discussion, and
>> perhaps for the community to decide on a way forward.
>> 
>> After a lot of deliberation and thinking both together and
>> individually, I think we reached an inflection point for ourselves.
>> While I don't want to speak for the others,
>> I will state my opinion. I think it's become apparent that Tinkerpop
>> as a project and a community is not a fit for the Apache Software
>> Foundation, and I see little potential for that to change.
>> This is not a statement that Tinkerpop is bad or evil. The ASF isn't
>> the only place projects live to be successful, nor is the Apache Way
>> the only method that successful projects adopt.
>> 
>> That said, the ASF cares deeply about it's existing culture and that
>> the communities that are here adopt "the Apache Way"; that's actually
>> a core tenant to accomplish during incubation. That leads
>> me (speaking only for myself) to believe that you would thrive better
>> elsewhere, rather than chafing and being unhappy, and eventually
>> failing to graduate.
>> 
>> --David
>> 
> 
> 
> -- 
> Rich Bowen - rbowen@rcbowen.com - @rbowen
> http://apachecon.com/ - @apachecon

Re: The future of Tinkerpop

[Rich Bowen <rb...@rcbowen.com>]

There's been some good discussion here. I'd like to make an observation 
- most of the best "let's fix this" discussion has come from people who 
are not on the PMC, while the PMC members have been largely silent.

This seems important to me. I would suggest that it indicates that there 
are a number of people who should be on the PMC who are not yet.

On 10/02/2015 09:08 AM, David Nalley wrote:
> Hi folks,
>
> A number of the mentors (Daniel, Rich, and I), along with several
> other IPMC members were in Budapest for ApacheCon; while there we
> discussed the state of
> Tinkerpop, it's incubation, and a number of other topics. I wanted to
> bring one of those topics here to foster a larger discussion, and
> perhaps for the community to decide on a way forward.
>
> After a lot of deliberation and thinking both together and
> individually, I think we reached an inflection point for ourselves.
> While I don't want to speak for the others,
> I will state my opinion. I think it's become apparent that Tinkerpop
> as a project and a community is not a fit for the Apache Software
> Foundation, and I see little potential for that to change.
> This is not a statement that Tinkerpop is bad or evil. The ASF isn't
> the only place projects live to be successful, nor is the Apache Way
> the only method that successful projects adopt.
>
> That said, the ASF cares deeply about it's existing culture and that
> the communities that are here adopt "the Apache Way"; that's actually
> a core tenant to accomplish during incubation. That leads
> me (speaking only for myself) to believe that you would thrive better
> elsewhere, rather than chafing and being unhappy, and eventually
> failing to graduate.
>
> --David
>


-- 
Rich Bowen - rbowen@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

Re: The future of Tinkerpop

[Jason Plurad <pl...@gmail.com>]

Thank you for your comments, David.

I think TinkerPop definitely fits into the Apache ecosystem. Out of the box
it has integrations with Apache Spark and Apache Giraph. If you pull in
Titan as the graph implementation, it uses Apache Cassandra or Apache
HBase. It is worth noting that Apache Falcon and Apache Atlas are using
TinkerPop (with Titan), although they haven't moved to the TinkerPop3
version yet. A member of the TinkerPop community presented on TinkerPop at
Apachecon in Austin in March. There was some discussion at Apachecon about
whether Apache Flink could leverage the TinkerPop Graph APIs. I think there
have been similar discussions about GraphX from Apache Spark.

I think the reason you are seeing the word "vendor" splashed around the
mailing list is because TinkerPop is a graph abstraction. For example,
other than TinkerGraph, it doesn't ship with an OLTP graph implementation.
The project has been very deliberate about what features to include such
that vendors can comply with the TinkerPop Graph APIs without pulling along
vendor-specific baggage. Perhaps it would be better if there were a
fully-featured TinkerPop reference implementation.

As far as decision making, I've noticed that a lot of discussion for
features is within the JIRAs themselves, but those notifications still end
up on the mailing list. There was recently a call for a community vote
whether to bump support to Hadoop 2.x, and that ended up getting many
responses from the community.

To sum up, I think there is a community here in TinkerPop that already
plays well within Apache. If there is an opportunity to correct course to
become better aligned with the Apache Way, I think it is definitely
something this community can make possible.


On Sun, Oct 4, 2015 at 1:50 PM, David Nalley <da...@gnsa.us> wrote:

> First my apologies on the delay of this response, with ApacheCon
> wrapping up, more international travel for most of us, and another
> impending conference, I've been slower than normal.
>
>
> Let me first start of though expressing a bit about both the structure
> and culture of the ASF. From a structural perspective, we really
> aren’t that unique. The number of organizations who have copied our
> organizational structure and governance model is a list scores long.
> Not all are perfect implementations, but rarely a month goes by in
> which we don’t hear ‘We modeled our project or organization based upon
> what works at the ASF’ At the end of the day, we are a corporation,
> organized as a public benefit charity, with a Board of Directors
> providing oversight of hundreds of projects. The board very rarely, if
> ever, interferes with technical decisions or the technical direction
> of the projects. But that is merely an organizational structure. The
> thing that sets the ASF apart is its culture, all of the above can be
> (and has been) replicated a number of times elsewhere, but culture and
> involvement as a group is important, and it’s also one of the things
> that is most tenuous when new projects come to the ASF. And while
> software is the ‘work product’ that we deliver, we consider the
> community of people who come together to build software, write
> documentation as well as all of the other tasks like testing, bug
> triaging, etc as far more important, and we want the community to have
> a connection with the other project communities and people at the ASF.
>
>
> I don’t have concerns about compliance with release policy, or other
> process issues. That seems pretty squared away.
>
> So with that out of the way, I have some primary concerns, and I may
> list some that others brought up during conversations in Budapest.
>
>
> First up is that the project doesn’t care about being a part of the
> larger Apache community. Members of the project have explicitly said
> so. This is the biggest problem for me, though some of the other are
> pretty serious in their own right.
>
>
> Vendors having status - this is something that’s come up before. Folks
> involved at the ASF are expected to act independently, as individuals.
> In terms of the project, getting influence because you are employed by
> a software vendor is problem. I see the phrase ‘vendors’ far too
> often. We shouldn’t be building software for ‘vendors’, our software
> is for the public at large, and a vendor employee that uses the
> software should have to earn merit in the same way as anyone else.
> Despite this being discussed several times, no change seems apparent.
>
>
> Decision-making is happening elsewhere. This is something that was
> called out in Budapest. The primary venue for decision making in
> Apache projects is the mailing list. Unfortunately we see
> pronouncements of decisions that were made, but precious little
> decision making, debate, etc.
>
>
> Any of these issues alone is problematic and terribly worrisome, and
> would block graduation. In aggregate it’s even more bleak.
>
>
> The following statement is not original with me, but I think it
> actively sums up the situation, and reflects how I feel about the
> situation.  “They want to cloak themselves in the Apache name, gain
> the protection and reputation that the ASF brings with it, but they
> don’t want to change the way they operate, or adopt the ASF culture.”
>
>
> In addition to those issues, I think there are a few more - that
> perhaps are worrying but not rising to the same level. One of those is
> that since joining the ASF diversity of the project (in terms of
> employers of committers/PMC) has gotten substantially worse.
>
> --David
>
>
> On Fri, Oct 2, 2015 at 3:08 PM, David Nalley <da...@gnsa.us> wrote:
> > Hi folks,
> >
> > A number of the mentors (Daniel, Rich, and I), along with several
> > other IPMC members were in Budapest for ApacheCon; while there we
> > discussed the state of
> > Tinkerpop, it's incubation, and a number of other topics. I wanted to
> > bring one of those topics here to foster a larger discussion, and
> > perhaps for the community to decide on a way forward.
> >
> > After a lot of deliberation and thinking both together and
> > individually, I think we reached an inflection point for ourselves.
> > While I don't want to speak for the others,
> > I will state my opinion. I think it's become apparent that Tinkerpop
> > as a project and a community is not a fit for the Apache Software
> > Foundation, and I see little potential for that to change.
> > This is not a statement that Tinkerpop is bad or evil. The ASF isn't
> > the only place projects live to be successful, nor is the Apache Way
> > the only method that successful projects adopt.
> >
> > That said, the ASF cares deeply about it's existing culture and that
> > the communities that are here adopt "the Apache Way"; that's actually
> > a core tenant to accomplish during incubation. That leads
> > me (speaking only for myself) to believe that you would thrive better
> > elsewhere, rather than chafing and being unhappy, and eventually
> > failing to graduate.
> >
> > --David
>



-- 
Have a good one,
Jason

Re: The future of Tinkerpop

[David Nalley <da...@gnsa.us>]

On Mon, Oct 5, 2015 at 1:27 AM, Stephen Mallette <sp...@gmail.com> 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

Re: The future of Tinkerpop

[Dylan Millikin <dy...@gmail.com>]

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 <hu...@apache.org> 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.
>

Re: The future of Tinkerpop

[David Robinson <dr...@gmail.com>]

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 <sp...@gmail.com>
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 <hu...@apache.org> 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.
> >
>

Re: The future of Tinkerpop

[Stephen Mallette <sp...@gmail.com>]

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 <hu...@apache.org> 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.
>

Re: The future of Tinkerpop

[Daniel Gruno <hu...@apache.org>]

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.

Re: The future of Tinkerpop

[Stephen Mallette <sp...@gmail.com>]

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 <hu...@apache.org> 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.
>

Re: The future of Tinkerpop

[Daniel Gruno <hu...@apache.org>]

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.

Re: The future of Tinkerpop

[Stephen Mallette <sp...@gmail.com>]

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 <hu...@apache.org> 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.
>

Re: The future of Tinkerpop

[Daniel Gruno <hu...@apache.org>]

[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.

Re: The future of Tinkerpop

[Matt Frantz <ma...@gmail.com>]

David,
Of the three issues that you seem to feel are grounds for ejection of the
project from the foundation, I wanted to offer my insight and also ask a
couple of questions.  As a latecomer to the TinkerPop community, I lack the
history of the founders, but feel that my perspective may, for that reason,
be valuable.

(1) Please clarify what you mean by "the project doesn't care about being a
part of the larger Apache community."  I'm fairly certain that you mean
something like "certain committers to the TinkerPop project have expressed
their respective, individual lack of interest in participating in other
Apache projects."  Is that more accurate?

(2) As Jason points out, the use of the term "vendor" appears to have
caused confusion for you and potentially for other mentors.  TinkerPop has
two interfaces.  One faces application developers and the other faces the
developers of conforming implementations, a.k.a. "vendors".  Is this
architecture unique among the Apache projects?  If there are indeed
precedents, then what is your preferred term?

(3) As someone who benefits from open communication amongst the committers,
I believe that there have been huge strides in transparency in recent
months.  Use of JIRA to host conversations about specific issues seems to
have increased.  The "dev" and "gremlin-users" lists are quite active with
conversations about potential improvements.  Perhaps the mentors, being
spread so thin, have not appreciated these improvements, but I certainly
have.  That said, we collectively need to continue to rely on
"on-the-record" dialogue, as it benefits on-boarding of potential new
committers, as well as providing accountability to the larger community of
vendors (a.k.a. implementers) and developers of applications and client
libraries.

As this thread indicates, we would appreciate a measure of transparency on
your part as well.  We can appreciate the efficiency of face-to-face
meetings that happen at conferences like Cassandra Summit and ApacheCon.
We certainly don't want to burden such meetings with stenographers that
could provide transcripts.  At least with respect to the channels that I
personally monitor, this "decision" (or perhaps "inclination") to eject
TinkerPop came as a surprise.  Hopefully it is not too late to consider
alternate points of view, and to invest in a bit more mentoring for the
participants, many of whom, like myself, are new to the Apache incubation
process.

Regards,
Matt

On Sun, Oct 4, 2015 at 10:50 AM, David Nalley <da...@gnsa.us> wrote:

> First my apologies on the delay of this response, with ApacheCon
> wrapping up, more international travel for most of us, and another
> impending conference, I've been slower than normal.
>
>
> Let me first start of though expressing a bit about both the structure
> and culture of the ASF. From a structural perspective, we really
> aren’t that unique. The number of organizations who have copied our
> organizational structure and governance model is a list scores long.
> Not all are perfect implementations, but rarely a month goes by in
> which we don’t hear ‘We modeled our project or organization based upon
> what works at the ASF’ At the end of the day, we are a corporation,
> organized as a public benefit charity, with a Board of Directors
> providing oversight of hundreds of projects. The board very rarely, if
> ever, interferes with technical decisions or the technical direction
> of the projects. But that is merely an organizational structure. The
> thing that sets the ASF apart is its culture, all of the above can be
> (and has been) replicated a number of times elsewhere, but culture and
> involvement as a group is important, and it’s also one of the things
> that is most tenuous when new projects come to the ASF. And while
> software is the ‘work product’ that we deliver, we consider the
> community of people who come together to build software, write
> documentation as well as all of the other tasks like testing, bug
> triaging, etc as far more important, and we want the community to have
> a connection with the other project communities and people at the ASF.
>
>
> I don’t have concerns about compliance with release policy, or other
> process issues. That seems pretty squared away.
>
> So with that out of the way, I have some primary concerns, and I may
> list some that others brought up during conversations in Budapest.
>
>
> First up is that the project doesn’t care about being a part of the
> larger Apache community. Members of the project have explicitly said
> so. This is the biggest problem for me, though some of the other are
> pretty serious in their own right.
>
>
> Vendors having status - this is something that’s come up before. Folks
> involved at the ASF are expected to act independently, as individuals.
> In terms of the project, getting influence because you are employed by
> a software vendor is problem. I see the phrase ‘vendors’ far too
> often. We shouldn’t be building software for ‘vendors’, our software
> is for the public at large, and a vendor employee that uses the
> software should have to earn merit in the same way as anyone else.
> Despite this being discussed several times, no change seems apparent.
>
>
> Decision-making is happening elsewhere. This is something that was
> called out in Budapest. The primary venue for decision making in
> Apache projects is the mailing list. Unfortunately we see
> pronouncements of decisions that were made, but precious little
> decision making, debate, etc.
>
>
> Any of these issues alone is problematic and terribly worrisome, and
> would block graduation. In aggregate it’s even more bleak.
>
>
> The following statement is not original with me, but I think it
> actively sums up the situation, and reflects how I feel about the
> situation.  “They want to cloak themselves in the Apache name, gain
> the protection and reputation that the ASF brings with it, but they
> don’t want to change the way they operate, or adopt the ASF culture.”
>
>
> In addition to those issues, I think there are a few more - that
> perhaps are worrying but not rising to the same level. One of those is
> that since joining the ASF diversity of the project (in terms of
> employers of committers/PMC) has gotten substantially worse.
>
> --David
>
>
> On Fri, Oct 2, 2015 at 3:08 PM, David Nalley <da...@gnsa.us> wrote:
> > Hi folks,
> >
> > A number of the mentors (Daniel, Rich, and I), along with several
> > other IPMC members were in Budapest for ApacheCon; while there we
> > discussed the state of
> > Tinkerpop, it's incubation, and a number of other topics. I wanted to
> > bring one of those topics here to foster a larger discussion, and
> > perhaps for the community to decide on a way forward.
> >
> > After a lot of deliberation and thinking both together and
> > individually, I think we reached an inflection point for ourselves.
> > While I don't want to speak for the others,
> > I will state my opinion. I think it's become apparent that Tinkerpop
> > as a project and a community is not a fit for the Apache Software
> > Foundation, and I see little potential for that to change.
> > This is not a statement that Tinkerpop is bad or evil. The ASF isn't
> > the only place projects live to be successful, nor is the Apache Way
> > the only method that successful projects adopt.
> >
> > That said, the ASF cares deeply about it's existing culture and that
> > the communities that are here adopt "the Apache Way"; that's actually
> > a core tenant to accomplish during incubation. That leads
> > me (speaking only for myself) to believe that you would thrive better
> > elsewhere, rather than chafing and being unhappy, and eventually
> > failing to graduate.
> >
> > --David
>

Re: The future of Tinkerpop

[David Nalley <da...@gnsa.us>]

First my apologies on the delay of this response, with ApacheCon
wrapping up, more international travel for most of us, and another
impending conference, I've been slower than normal.


Let me first start of though expressing a bit about both the structure
and culture of the ASF. From a structural perspective, we really
aren’t that unique. The number of organizations who have copied our
organizational structure and governance model is a list scores long.
Not all are perfect implementations, but rarely a month goes by in
which we don’t hear ‘We modeled our project or organization based upon
what works at the ASF’ At the end of the day, we are a corporation,
organized as a public benefit charity, with a Board of Directors
providing oversight of hundreds of projects. The board very rarely, if
ever, interferes with technical decisions or the technical direction
of the projects. But that is merely an organizational structure. The
thing that sets the ASF apart is its culture, all of the above can be
(and has been) replicated a number of times elsewhere, but culture and
involvement as a group is important, and it’s also one of the things
that is most tenuous when new projects come to the ASF. And while
software is the ‘work product’ that we deliver, we consider the
community of people who come together to build software, write
documentation as well as all of the other tasks like testing, bug
triaging, etc as far more important, and we want the community to have
a connection with the other project communities and people at the ASF.


I don’t have concerns about compliance with release policy, or other
process issues. That seems pretty squared away.

So with that out of the way, I have some primary concerns, and I may
list some that others brought up during conversations in Budapest.


First up is that the project doesn’t care about being a part of the
larger Apache community. Members of the project have explicitly said
so. This is the biggest problem for me, though some of the other are
pretty serious in their own right.


Vendors having status - this is something that’s come up before. Folks
involved at the ASF are expected to act independently, as individuals.
In terms of the project, getting influence because you are employed by
a software vendor is problem. I see the phrase ‘vendors’ far too
often. We shouldn’t be building software for ‘vendors’, our software
is for the public at large, and a vendor employee that uses the
software should have to earn merit in the same way as anyone else.
Despite this being discussed several times, no change seems apparent.


Decision-making is happening elsewhere. This is something that was
called out in Budapest. The primary venue for decision making in
Apache projects is the mailing list. Unfortunately we see
pronouncements of decisions that were made, but precious little
decision making, debate, etc.


Any of these issues alone is problematic and terribly worrisome, and
would block graduation. In aggregate it’s even more bleak.


The following statement is not original with me, but I think it
actively sums up the situation, and reflects how I feel about the
situation.  “They want to cloak themselves in the Apache name, gain
the protection and reputation that the ASF brings with it, but they
don’t want to change the way they operate, or adopt the ASF culture.”


In addition to those issues, I think there are a few more - that
perhaps are worrying but not rising to the same level. One of those is
that since joining the ASF diversity of the project (in terms of
employers of committers/PMC) has gotten substantially worse.

--David


On Fri, Oct 2, 2015 at 3:08 PM, David Nalley <da...@gnsa.us> wrote:
> Hi folks,
>
> A number of the mentors (Daniel, Rich, and I), along with several
> other IPMC members were in Budapest for ApacheCon; while there we
> discussed the state of
> Tinkerpop, it's incubation, and a number of other topics. I wanted to
> bring one of those topics here to foster a larger discussion, and
> perhaps for the community to decide on a way forward.
>
> After a lot of deliberation and thinking both together and
> individually, I think we reached an inflection point for ourselves.
> While I don't want to speak for the others,
> I will state my opinion. I think it's become apparent that Tinkerpop
> as a project and a community is not a fit for the Apache Software
> Foundation, and I see little potential for that to change.
> This is not a statement that Tinkerpop is bad or evil. The ASF isn't
> the only place projects live to be successful, nor is the Apache Way
> the only method that successful projects adopt.
>
> That said, the ASF cares deeply about it's existing culture and that
> the communities that are here adopt "the Apache Way"; that's actually
> a core tenant to accomplish during incubation. That leads
> me (speaking only for myself) to believe that you would thrive better
> elsewhere, rather than chafing and being unhappy, and eventually
> failing to graduate.
>
> --David