incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <ro...@shaposhnik.org>
Subject Re: Should Apache VOTEs be in a first-come, first-serve queue?
Date Mon, 14 Sep 2015 23:11:49 GMT
Hi Marko,

On Mon, Sep 14, 2015 at 2:51 PM, Marko Rodriguez <okrammarko@gmail.com> wrote:
>> I think that Marvin's question to you was pretty cogent. Would you be
>> willing to spend an hour or so each on 5 different projects you aren't
>> involved in before getting to put your own project up for a release? Would
>> it change your willingness if most of the community behind some of those
>> projects not only aren't willing to review your project, but they aren't
>> even willing to review their own project carefully and cast a vote?
>
> I use Apache, I am not Apache.

Thanks for making a clear statement because it lets me focus on the
question that may be central to this discussion: can you tell us why
did you guys decided to join ASF in the first place? This is not a baited
question: I'm genuinely curious about what kind of expectations did
you have when joining and what did you want to achieve?

Because, you see, a project that's part of the foundation can't simply
be just 'using' the foundation, it actually has to become part of the
foundation, in my mind.

> I don't expect the users of TinkerPop to have to write my code, they are
> there to use it.

Well, that a bit black-n-white. Certainly folks who don't want to write
TinkerPop code can't be forcefully compelled to do so. Yet, somehow,
the way you phrased it makes me suspect that you see it as a firewall
between the two communities of users vs. developers. Am I reading
this wrong?

> If I'm not delivering software in a timely manner,

*you* (as in Marko Rodriguez) are not delivering software. Your entire
development community does. It is a subtle but important distinction
that goes to heart of the Apache Governance model: we don't allow
BDFLs. Anyone who's part of your community can propose a release
at any time.

> Likewise for Apache Incubation (though perhaps I'm naive in my assumptions) -- if you
> are a mentor, move the artifacts through in a timely manner and don't wait for the
> project leaders to ping "Hey, can we get a VOTE?…please…pretty please….hello?"

That's a very legitimate point. As Ross mentioned a couple of times if there's
one actionable AI from this thread this would be feedback to your mentors.
Your mentors are your first line of defense on things like release VOTES.
That said, they are not the only line of defense. Any IPMC member can
vote on your release. But the trick is -- you've got to incentivize
them somehow.
And no -- $20 won't cut it and is morally wrong. What will cut it is paying
it forward perhaps along the lines that Marvin suggested.

Let me give you an analogy. You've immigrated to a foreign country and
you find it difficult to befriend people. Your hosts are busy with other things
and are not facilitating your relationships as quickly as you would like them
to do that. At that point 'buying' friends is not really an option, is
it? Winning
friends is. Now, you may say -- what if I'm a total misanthrope who can't stand
other human beings? Well, in that case something like ASF wouldn't work
for you. Unlike a foreign country, where you can try to rely on government
and other services and attempt never to find out your neighbor's names, ASF
is not setup like that. We're a community of volunteers and the only currency
we accept is other volunteer's contributions of value.

>> Your answers will likely say a lot about the dynamics of getting people to
>> help each other. It is hard to do and a human touch goes further than
>> setting hurdles.
>
> This is where I lose you guys. Why are humans involved in a process that should be automated.
>
>         1. MD5, SHA1, PGP can be automatically checked.
>         2. Unzip and see if the data is corrupted can be done automatically.
>         3. LICENSE verification is difficult, but I suspect with some markup language
for LICENSE and pom.xml analysis, this can be done automatically.
>         4. mvn clean install (BUILD SUCCESS can be verified automatically).
>         5. ...

Because if I had 5c for every time a novel way to screw up IP hygiene comes
up in young communities I'd be a millionaire. In fact, if you ever worked for
a commercial company that produces software based on open source projects
you must've done something like a Black Duck scan. I don't have to tell
you what kind of things get uncovered. Long story short: "a dude-in-the-loop"
stays ;-)

Now, here's how you can make that dude's life so easy that not voting on
your release would not make any sense -- automate EVERYTHING that
can be automated and include the results in your VOTE thread. Better yet:
give me a Docker container where $ docker run will repro everything you've
automated by on my own workstation.

Then you can turn this conversation around and ask: what ELSE are your
mentors spending their time on. And those things better be various human-level
heuristics.

Thanks,
Roman.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message