Re: Link to DRAFT schedule for apacheCON CORE:

[Pierre Smits <pi...@gmail.com>]

First, I don't speak on behalf of others...

For what it is worth, I have neither submitted multiple talks to increase
the changes of acceptance nor advised others to do so.
That some in the OFBiz community/track submitted multiple talks has mainly
to do with the fact that Apache OFBiz is applicable in various (industry)
sectors, but also at various levels of organisational maturity. Our
adopters and contributors come from a broad spectrum of interest, so we got
14 talks submitted by our contributors that cater to that diversity. If
increasing the odds would have been the deciding reason for submitting
multiple talks, I and others from the OFBiz community could have submitted
way more than we have done.

I adviced the speaker of the Trafodion talk in BigData to also do a pitch
in your Shark session, Roman, as Trafodion is in the incubation process. I
advised that based on the simple argument that a podling can use attention
a bit more than an existing project visavis building a healthy contributors
community.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Wed, Jul 8, 2015 at 8:00 PM, Roman Shaposhnik <rv...@apache.org> wrote:

> On Wed, Jul 8, 2015 at 10:50 AM, jan i <ja...@apache.org> wrote:
> >> Thanks! That said the changes I'm about to propose are sort
> >> of big. I wish I had time to tweak things before they got
> semi-finalized.
> >> Still I think it is better to tweak now than to have tracks with talks
> >> that don't belong to them.
> >
> > I strongly disagree. We have for every AC I have helped with, started
> with
> > tracks, and at the end added talks where there was gaps, no different
> than
> > this time.
>
> Like I said -- I apologize for not being available in some of these
> discussions.
> But I can't just stand by when I see a talk on JSR 354 in a NoSQL/SQL
> track.
>
> I'm all for minimizing changes at this point, but lets see if the
> minimum surgery
> will help making it better.
>
> >> And now a bit of feedback: the talks I personally care about very
> >> much got accepted (good!) but they are all in different, and what's
> >> more important, weird tracks. Let me give you a couple of examples:
> >>    0. A few talks got misclassified when submitted (or got submitted to
> >>    both CORE and Bigdata). E.g.:
> >>         * Apache Sentry makes WAY more sense in Bigdata side of
> >>           the conference (it is only applicable to Hadoop ecosystem)
> >>           or Security track in CORE
> >
> > But it is a podling too, and then per definition also suited for the
> > incubator track.
>
> But so is Kylin and a few others. I understand why Sentry submitted
> to both track (that would be to increase their chances of acceptance --
> I see a lot of submitters did that) but I see it as unfair to pick it as
> THE ONLY bigdata talk to be in the Incubator track.
>
> >>         *   "Engineering, Business & Legal Choices for Bringing
> >>              Commercial Software to Open Source"
> >>              makes way more sense in CORE Incubator track
> >
> > But I cannot find it in the CFP for apacheCON CORE:
>
> That was a mistake on the part of original submitter (I contacted them).
>
> So here's my first proposal for a minimal surgery:
>    push Sentry to bigdata
> get
>    Engineering, Business & Legal...
> into Incubator track in its place.
>
> Can I please make that change?
>
> >>    1. Zest as part of dev tools track doesn't really make much sense
> >>     (Zest is way more about computer science than tooling).
> >>
> >>    2. Groovy JSR 354 talk makes no sense in NoSQL/SQL track
> >
> > ups forgot to remove that title.
>
> Are you saying this talk will be removed for good from the CORE?
> If that's the case -- I'd have to disagree very strongly. That would
> leave only one talk on Groovy in the CORE. In general Groovy
> talks are a big draw for the audience -- I think it is in our best
> interest to maximize for that at least somewhat.
>
> Thanks,
> Roman.
>