[openstack-community] OpenStack Summit proposal voting - not a fan

Tristan Goode tristan at aptira.com
Thu Feb 20 21:05:37 UTC 2014


I tend to agree. Perhaps voting could be limited to those that have RSVPed
and are actually going to the Summit as well?



In an effort to do my best and look at all the submissions, I voted for a
combined several hours in a few goes yesterday and still haven't reached
any kind of end. It did seem like presentations came past multiple times
and the volume of talks with a tenuous link to OpenStack made it a
challenge.



There were also talks in there that were submitted for HKG that had NOT
been submitted to ATL. I confirmed this with a couple of submitters.



It also seemed like some folks submit several talks that are almost the
same, and some people just submit too many talks. Perhaps a one or two talk
per person limit. Or one talk and one panel.



This time I do hope we don't see the combination of talks like we had in
HKG which I thought was a good idea as a track chair beforehand, but when I
went and saw them on some occasions I felt for the speakers.



Am going to have another crack at finishing my voting today. Wish me luck
:-P





*From:* Adam Nelson [mailto:adam at varud.com]
*Sent:* Friday, 21 February 2014 4:04 AM
*To:* Dave Neary
*Cc:* community at lists.openstack.org
*Subject:* Re: [openstack-community] OpenStack Summit proposal voting - not
a fan



Lots of conferences do this to boost interest and engage with the
community.... but you're absolutely right.



A good compromise would be to give track leaders some magic votes to boost
certain talks and veto others.



One way to implement this would be to allow tracks to have their own
algorithms.  Openstack is too broad to have one method for all the talks
and I think it's totally reasonable to have a default method which track
chairs can override.



-Adam


--

Kili - Cloud for Africa: kili.io

Musings: twitter.com/varud <https://twitter.com/varud>

More Musings: varud.com

About Adam: www.linkedin.com/in/adamcnelson



On Thu, Feb 20, 2014 at 6:51 PM, Dave Neary <dneary at redhat.com> wrote:

Hi all,

Rather than just complain into the ether, I wanted to let people know
why I don't like the voting process for conference proposals and see if
I'm the only one.

I don't think that the voting process is the best way to gauge whether
proposals will be good for the conference. There are a few reasons for that:

* Having to hawk & promote proposal(s) is kind of unseemly, and makes us
look small, I think. Hundreds of people going "vote for me!" doesn't
make us look good.
* Some people don't want to pitch themselves, others don't have access
to as big a platform to promote
* The same issues exist with this system which exist with board voting -
there is a possibility that people will vote for their colleagues, not
out of any corruption, but just because no-one has time to rate all the
proposals, and they're more likely to rate those submitted by people
they know more highly
* Also, it's a self-selecting group of people who rate proposals - I
don't think voters will be representative of summit attendees
* After all is said and done, the proposals which are chosen by the
voters are guidelines to the people who choose the talks for the tracks,
the track leaders

I have been a track leader for the last number of summits, and I've seen
first hand great presentations get very low numbers of votes, while
others which are not as interesting get very high numbers of votes and
high ratings.

Personally, I would be happy if we could change the system to remove the
"pimp my talk" aspect for Summits.

Cheers,
Dave.

--
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13

_______________________________________________
Community mailing list
Community at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/community/attachments/20140221/5f48b4e9/attachment.html>


More information about the Community mailing list