You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Rob Vesse <rv...@dotnetrdf.org> on 2015/06/02 10:57:02 UTC
Re: Recognition of Votes
Marko
Congratulations on putting together another great release, hopefully the
IPMC review will go more smoothly this time
Comments inline:
On 01/06/2015 16:31, "Marko Rodriguez" <ok...@gmail.com> wrote:
>Hello,
>
>The TinkerPop 3.0.0.M9-incubating VOTE is now closed:
>
> PMC: +1 (4), 0 (0), -1 (0) -- one from mentor.
>
>While Apache only recognizes the votes of the PMC,
Not true, only PMC votes are considered legally binding from an ASF
standpoint but the wider community is always welcome (and should be
encouraged) to review and vote on a release. This is particularly useful
as you promote community members up through the ranks of committer and PMC
as they gain merit since it helps them learn the tasks that a PMC member
has to perform. In other projects I've been involved in willingness to
actually take the time to review a release has been one of the criteria
we've used to asses potential PMC members.
Note that it is always the PMC (and more specifically the release manager
for the release) who have the final say. If you get enough binding votes
and have more positive than negative votes a release manager can (but
usually shouldn't) choose to go ahead with the release regardless,
generally it boils down to context.
http://www.apache.org/foundation/voting.html#ReleaseVotes
If there is a legal issue then you MUST cancel the release and respin to
resolve this as otherwise you can cause serious headaches for the ASF (and
in the worse case the board could formally retract your release) but if it
was some minor functional issue/bug where you wanted to punt it to a
future release then perhaps you would go ahead anyway. In that case it
would be a judgement call as to how badly the issue would affect the
community in the meantime.
> I think it is important to express the thoughts of the wider community
>given that TinkerPop is leveraged in the products of various graph system
>vendors.
>
> Committers: +1 (1), 0 (0), -1 (0)
> Vendors: +1 (3), 0 (0), -1 (0)
It is always acceptable (and encouraged) to include such information in
vote results.
However please remember that Apache projects are supposed to be vendor
neutral and vendor votes should not be treated any differently from votes
by any other community member. People who work at vendors on products
that use Tinkerpop are always welcome to vote as individual members of the
community, the fact that they happen to work at vendors should not give
their votes any special significance
The general practise that I've seen used in other Apache projects is
simply to report the total number of votes and state how many where
binding in each category. So for your result you might have instead
reported like so:
+1 - 7 (4 binding)
0 - 0
-1 - 0
Which has the advantage of conveying the necessary legal information from
an ASF standpoint while not treating community votes as a separate lesser
thing
Note that some projects also choose to list the people who voted in each
category though this is more a preference thing and depends on the volume
of votes you receive, smaller projects tend to do this while larger ones
often do not though honestly I haven't seen much consistency around this
Rob
Re: Recognition of Votes
Posted by Rich Bowen <rb...@rcbowen.com>.
On 06/04/2015 10:30 AM, Marko Rodriguez wrote:
> Hi David,
>
> Perhaps the terminology is off -- a vendor is someone who builds a product on TinkerPop. Is that product commercial/for sale? Is that product a personal project or a company project? I dunno… Lets list them:
>
> Titan: OLTP/OLAP graph database. Free product. Company product.
> Neo4j: OLTP graph database. Commercial product. Company project.
> OrientDB: OLTP graph database. Free product. Company project.
> Gremlin-Scala: Gremlin language variant. Free product. Personal project.
> Gremlin-JavaScript: Gremlin language variant. Free product. Personal project.
> Ogre: Gremlin language variant. Free product. Personal project.
> Pacer: Gremlin language variant. Free product. Company project.
> InfiniteGraph: OLTP graph database. Commercial product. Company project.
> Bulbs: Python framework. Free product. Personal project.
> SQLg: OLTP graph database. Free product. Personal project.
> ….
> http://tinkerpop.incubator.apache.org/ (see community contributors)
>
> A vendor is not about "making money" or being in a "company." A vendor is someone who provides a TinkerPop-enabled application. TinkerPop is nothing without these vendors as TinkerPop is pointless in and of itself, it needs to be integrated into other technologies to "do something." Its like the JDBC -- if no relational database uses the JDBC, well, that was for naught.
>
> To conclude, this has nothing do with money, who works for who… it has to do with how is TinkerPop going to get the biggest outreach and satisfy the most users. In other words, its about TinkerPop growing its community. TinkerPop doesn't have a direct communication line to users, it has it via its vendors who release TinkerPop-enabled products.
>
> Perhaps a change of terminology would be best? Is there a better word than "vendor" that will alleviate any semantic jitters in the ASF?
>
It's not so much about whether they're making money at it. It's that
participation in the ASF is always individual, not corporations. If
these organizations have someone that works with the product, works with
the code, writes documentation, whatever, they are likely a candidate
for the PMC, or as a committer, because they are a participant. Note
that one doesn't have to write *code* to be a PMC member. Anyone that
plays a critical role in deciding the direction of the project, and who
has earned the trust of the community, would be a reasonable person to
consider.
A "vendor" doesn't have a vote in the direction of the project, whether
or not their entire business relies on Tinkerpop. However, an individual
who works at that vendor can, and should, earn merit in the community so
that they have that vote.
Yes, it can feel like a slippery distinction.
--
Rich Bowen - rbowen@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon
Re: Recognition of Votes
Posted by Marko Rodriguez <ok...@gmail.com>.
Hi David,
Perhaps the terminology is off -- a vendor is someone who builds a product on TinkerPop. Is that product commercial/for sale? Is that product a personal project or a company project? I dunno… Lets list them:
Titan: OLTP/OLAP graph database. Free product. Company product.
Neo4j: OLTP graph database. Commercial product. Company project.
OrientDB: OLTP graph database. Free product. Company project.
Gremlin-Scala: Gremlin language variant. Free product. Personal project.
Gremlin-JavaScript: Gremlin language variant. Free product. Personal project.
Ogre: Gremlin language variant. Free product. Personal project.
Pacer: Gremlin language variant. Free product. Company project.
InfiniteGraph: OLTP graph database. Commercial product. Company project.
Bulbs: Python framework. Free product. Personal project.
SQLg: OLTP graph database. Free product. Personal project.
….
http://tinkerpop.incubator.apache.org/ (see community contributors)
A vendor is not about "making money" or being in a "company." A vendor is someone who provides a TinkerPop-enabled application. TinkerPop is nothing without these vendors as TinkerPop is pointless in and of itself, it needs to be integrated into other technologies to "do something." Its like the JDBC -- if no relational database uses the JDBC, well, that was for naught.
To conclude, this has nothing do with money, who works for who… it has to do with how is TinkerPop going to get the biggest outreach and satisfy the most users. In other words, its about TinkerPop growing its community. TinkerPop doesn't have a direct communication line to users, it has it via its vendors who release TinkerPop-enabled products.
Perhaps a change of terminology would be best? Is there a better word than "vendor" that will alleviate any semantic jitters in the ASF?
Thanks David,
Marko.
http://markorodriguez.com
On Jun 3, 2015, at 5:36 PM, David Nalley <da...@gnsa.us> wrote:
> On Tue, Jun 2, 2015 at 9:36 AM, Marko Rodriguez <ok...@gmail.com> wrote:
>> Hello Rob,
>>
>>> Not true, only PMC votes are considered legally binding from an ASF
>>> standpoint but the wider community is always welcome (and should be
>>> encouraged) to review and vote on a release.
>>
>> That is good to know. I sometimes feel like we lost the energy of our "contributors" when we went TinkerPop went Apache. TinkerPop Contributors was 20+ individuals from various companies and vendor products. Its good to hear that doing the "side votes/recommendations" is considered a good thing. Without the vendors saying "this release works for our product," the VOTE of a PMC really doesn't matter in my opinion.
>>
>
> So first, you want people voting on releases. More is better. Many
> projects watch the people consistently voting on releases as people to
> consider for becoming a committer or PMC member. Particularly when the
> people voting are doing a good job of testing, auditing, voting.
>
> That said, the last sentence in that paragraph bothers me. I am sure
> this is merely a subtle distinction, but I want to be very explicit.
> Vendors, and indeed any corporate entity have no standing at the ASF.
> Who you work for has zero bearing on the validity of arguments, and
> technical reasoning, and should have zero influence. Actually, MUST
> have zero influence. If a project is found to have undue influence
> from a commercial entity, that would be cause for concern. It would be
> cause for the Board to become involved to resolve the issue, or to
> remove the PMC members allowing that to happen. There are lots of
> essays on project independence at the ASF; but the bottom line is that
> the PMC is the only body that matters in the project. It must
> maintain its independence and not abdicate its responsibilities to
> vendors or any other group.
>
> If this project were a top level project, the vote email showing a
> delineation between vendors and non-vendors would draw a lot of ire
> and much closer oversight from the board until the issue was resolved.
>
>>> However please remember that Apache projects are supposed to be vendor
>>> neutral and vendor votes should not be treated any differently from votes
>>> by any other community member. People who work at vendors on products
>>> that use Tinkerpop are always welcome to vote as individual members of the
>>> community, the fact that they happen to work at vendors should not give
>>> their votes any special significance
>>
>> I understand that philosophy and I like it. I love how its all about the individual at Apache. With that said, we do work closely with individuals at vendor companies and their yay or nay is crucial given how much more they are testing a TinkerPop release than, lets say, someone who is excited for feature X in the next release. I guess the distinction is not "vendor vs. consumer" but more "heavily tested vs. excited for a release."
>>
>
> So, it can't matter who a person works for here. And I think it's
> deleterious to efforts around building a community. You are explicitly
> in the above paragraph devaluing contributions from anyone who isn't
> employed by a graph database vendor. That type of attitude and
> conversation makes those folks feel less valuable, and thus care less
> about contributing to your project. We care about the actual work that
> people do, that is how you earn merit, and that is how you get a say
> (or binding vote) in a project.
> If you're successful in growing a vibrant project community it won't
> matter. You'll end up with users of your software who become as
> important, and who test as rigidly or more so than a vendor. You'll
> end up with users of your software who will morph into developers of
> your software. They will have corner cases in real life that will find
> things that vendors never considered; and their opinion must matter as
> much as someone who has a shiny $vendor.com email address.
>
>
>>>
>>> The general practise that I've seen used in other Apache projects is
>>> simply to report the total number of votes and state how many where
>>> binding in each category. So for your result you might have instead
>>> reported like so:
>>>
>>> +1 - 7 (4 binding)
>>> 0 - 0
>>> -1 - 0
>>
>
> Yes, please list the names of the folks placing 'binding' votes. That
> will help down the road when you or someone else goes back to audit.
>
>> What does "binding" mean? Isn't every VOTE binding?
>>
>> Thank you for your time Rob,
>> Marko.
>>
>> http://markorodriguez.com
>
> --David
Re: Recognition of Votes
Posted by David Nalley <da...@gnsa.us>.
On Tue, Jun 2, 2015 at 9:36 AM, Marko Rodriguez <ok...@gmail.com> wrote:
> Hello Rob,
>
>> Not true, only PMC votes are considered legally binding from an ASF
>> standpoint but the wider community is always welcome (and should be
>> encouraged) to review and vote on a release.
>
> That is good to know. I sometimes feel like we lost the energy of our "contributors" when we went TinkerPop went Apache. TinkerPop Contributors was 20+ individuals from various companies and vendor products. Its good to hear that doing the "side votes/recommendations" is considered a good thing. Without the vendors saying "this release works for our product," the VOTE of a PMC really doesn't matter in my opinion.
>
So first, you want people voting on releases. More is better. Many
projects watch the people consistently voting on releases as people to
consider for becoming a committer or PMC member. Particularly when the
people voting are doing a good job of testing, auditing, voting.
That said, the last sentence in that paragraph bothers me. I am sure
this is merely a subtle distinction, but I want to be very explicit.
Vendors, and indeed any corporate entity have no standing at the ASF.
Who you work for has zero bearing on the validity of arguments, and
technical reasoning, and should have zero influence. Actually, MUST
have zero influence. If a project is found to have undue influence
from a commercial entity, that would be cause for concern. It would be
cause for the Board to become involved to resolve the issue, or to
remove the PMC members allowing that to happen. There are lots of
essays on project independence at the ASF; but the bottom line is that
the PMC is the only body that matters in the project. It must
maintain its independence and not abdicate its responsibilities to
vendors or any other group.
If this project were a top level project, the vote email showing a
delineation between vendors and non-vendors would draw a lot of ire
and much closer oversight from the board until the issue was resolved.
>> However please remember that Apache projects are supposed to be vendor
>> neutral and vendor votes should not be treated any differently from votes
>> by any other community member. People who work at vendors on products
>> that use Tinkerpop are always welcome to vote as individual members of the
>> community, the fact that they happen to work at vendors should not give
>> their votes any special significance
>
> I understand that philosophy and I like it. I love how its all about the individual at Apache. With that said, we do work closely with individuals at vendor companies and their yay or nay is crucial given how much more they are testing a TinkerPop release than, lets say, someone who is excited for feature X in the next release. I guess the distinction is not "vendor vs. consumer" but more "heavily tested vs. excited for a release."
>
So, it can't matter who a person works for here. And I think it's
deleterious to efforts around building a community. You are explicitly
in the above paragraph devaluing contributions from anyone who isn't
employed by a graph database vendor. That type of attitude and
conversation makes those folks feel less valuable, and thus care less
about contributing to your project. We care about the actual work that
people do, that is how you earn merit, and that is how you get a say
(or binding vote) in a project.
If you're successful in growing a vibrant project community it won't
matter. You'll end up with users of your software who become as
important, and who test as rigidly or more so than a vendor. You'll
end up with users of your software who will morph into developers of
your software. They will have corner cases in real life that will find
things that vendors never considered; and their opinion must matter as
much as someone who has a shiny $vendor.com email address.
>>
>> The general practise that I've seen used in other Apache projects is
>> simply to report the total number of votes and state how many where
>> binding in each category. So for your result you might have instead
>> reported like so:
>>
>> +1 - 7 (4 binding)
>> 0 - 0
>> -1 - 0
>
Yes, please list the names of the folks placing 'binding' votes. That
will help down the road when you or someone else goes back to audit.
> What does "binding" mean? Isn't every VOTE binding?
>
> Thank you for your time Rob,
> Marko.
>
> http://markorodriguez.com
--David
Re: Recognition of Votes
Posted by Marko Rodriguez <ok...@gmail.com>.
Hi Rich,
>> That is good to know. I sometimes feel like we lost the energy of our "contributors" when we went TinkerPop went Apache. TinkerPop Contributors was 20+ individuals from various companies and vendor products.
>
> When you entered the incubator, you decided to limit the list of committers to a small subset of those listed as contributors on the former Tinkerpop website. At the time, this was called out as possibly problematic, in that it created two classes of contributors. Perhaps it is time to rectify this situation, and give full rights to those members of the developer community who were determined not worth in the first cut.
Here is the problem. Many of those contributors were commercial entities that had a developer from their company "represent" the company's interests in the direction of TinkerPop (as it related to their project). However, it also had individual entities that represented their technology's interest. We decided to swipe both categories of contributors due to the commercial interest of the "company entities" and stuck with: "Who deals with TinkerPop day-to-day --- coding, testing, promoting, etc."
I think we will slowly grow back our Apache TinkerPop contributors as more and more individuals chip in. In fact, there are 2 individuals we are interested in making new committers. An email soon to private@ to DISCUSS.
Thank you Rich,
Marko.
http://markorodriguez.com
Re: Recognition of Votes
Posted by Rich Bowen <rb...@rcbowen.com>.
On 06/02/2015 09:36 AM, Marko Rodriguez wrote:
> Hello Rob,
>
>> >Not true, only PMC votes are considered legally binding from an ASF
>> >standpoint but the wider community is always welcome (and should be
>> >encouraged) to review and vote on a release.
> That is good to know. I sometimes feel like we lost the energy of our "contributors" when we went TinkerPop went Apache. TinkerPop Contributors was 20+ individuals from various companies and vendor products.
When you entered the incubator, you decided to limit the list of
committers to a small subset of those listed as contributors on the
former Tinkerpop website. At the time, this was called out as possibly
problematic, in that it created two classes of contributors. Perhaps it
is time to rectify this situation, and give full rights to those members
of the developer community who were determined not worth in the first cut.
--
Rich Bowen - rbowen@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon
Re: Recognition of Votes
Posted by Marko Rodriguez <ok...@gmail.com>.
Hi,
>> What does "binding" mean? Isn't every VOTE binding?
I just read about it on the link you sent.
http://www.apache.org/foundation/voting.html#ReleaseVotes
Only PMC votes are binding. Others can VOTE, but theirs is not bindings.
Cool,
Marko.
Re: Recognition of Votes
Posted by Marko Rodriguez <ok...@gmail.com>.
Hello Rob,
> Not true, only PMC votes are considered legally binding from an ASF
> standpoint but the wider community is always welcome (and should be
> encouraged) to review and vote on a release.
That is good to know. I sometimes feel like we lost the energy of our "contributors" when we went TinkerPop went Apache. TinkerPop Contributors was 20+ individuals from various companies and vendor products. Its good to hear that doing the "side votes/recommendations" is considered a good thing. Without the vendors saying "this release works for our product," the VOTE of a PMC really doesn't matter in my opinion.
> However please remember that Apache projects are supposed to be vendor
> neutral and vendor votes should not be treated any differently from votes
> by any other community member. People who work at vendors on products
> that use Tinkerpop are always welcome to vote as individual members of the
> community, the fact that they happen to work at vendors should not give
> their votes any special significance
I understand that philosophy and I like it. I love how its all about the individual at Apache. With that said, we do work closely with individuals at vendor companies and their yay or nay is crucial given how much more they are testing a TinkerPop release than, lets say, someone who is excited for feature X in the next release. I guess the distinction is not "vendor vs. consumer" but more "heavily tested vs. excited for a release."
>
> The general practise that I've seen used in other Apache projects is
> simply to report the total number of votes and state how many where
> binding in each category. So for your result you might have instead
> reported like so:
>
> +1 - 7 (4 binding)
> 0 - 0
> -1 - 0
What does "binding" mean? Isn't every VOTE binding?
Thank you for your time Rob,
Marko.
http://markorodriguez.com