Open Stack

On 18/05/16 09:14, Florian Haas wrote:
> On 05/18/2016 12:24 AM, Stefano Maffulli wrote:
>> On 05/17/2016 12:40 PM, Claire Massey wrote:
>>> With the growing number of speaking submissions (we had 1,300 for
>>> Austin), some community members have expressed concerns about social
>>> media channels and email getting spammed during the week of voting. We
>>> also think many community members are unclear as to how much the votes
>>> weigh on the final decision. For example, some think that if someone
>>> campaigns for votes or asks their colleagues to vote, the session will
>>> likely be accepted (which may not be the case).
>> I have always considered the public voting a celebration of the success
>> of the summit and nothing else. It's a ritual for the OpenStack
>> community: twice a year we ask speakers to propose their talks and we
>> celebrate all of the submissions. In this celebration, people from
>> anywhere (the crowd) give their opinions...
>>
>> The rituals and the celebrations contribute to define communities,
>> online and not.
>>
>> I've argued at length that the crowd's votes are a by-product of the
>> celebration and are to be discarded by the track chairs.
If this is only for publicity - then it could be considered a complete
and total
waste of time to even start the voting process.

Promote the sessions. Asking people to vote and then throw their efforts
and opinion
away could actually be considered an insult.

For what it is worth - I personally think we should do away with it all
together
> And for what it's worth I have objected to this and will continue to do
> so. I believe we agree that track chairs should not consider the
> community vote to be binding. I believe we disagree, however, in that
> you're arguing the community vote should be discarded, while I very much
> believe track chairs should consider it.
>
>> The crowd has
>> no wisdom in this context, it can and will be easily manipulated (think
>> what happened when Pilates run a popularity contest asking the crowd to
>> vote).
> I agree with the second part of this sentence (unless we're discussing
> historical accuracy ;) ), but I very much disagree with the first.
>
>> Track chairs should be trusted instead, therefore they need to be
>> picked carefully (like they've been).
>>
>>> [...]Our thinking is that by removing voting from
>>> the process, we will:
>>>
>>> - Save valuable time during the overall Summit programming process,
>>> which should allow us to publish the final agenda and notify speakers
>>> sooner 
>>> - Allow our development teams more time to focus on improving the mobile
>>> app and web schedule developed during the last Summit cycle
>> These considerations by Foundation staff are very practical and it's
>> hard to counter these. Time is not compressible and it's quite clear
>> that development efforts are already stretching the team thin.
>>
>> My vote is to keep the celebrations pre-summit but not at the expense of
>> dev team's sanity. The executives at the foundation are the best judges
>> for this.
> If I may ask one provocative question. Pretty much every Summit I get an
> email from a new person at the Foundation I haven't met before, and/or
> who didn't work for the Foundation the Summit before. So I am guessing
> that ramping up headcount isn't an issue for the Foundation, neither for
> funding nor for organizational considerations. [Please correct me if I'm
> wrong here.] If the dev team is overloaded to the point of insanity, is
> it really an issue to give them more help?
>
> Yes, I've read Brooks. I'm not arguing that hiring (or contracting out
> to) additional developers will have a short-term positive impact. But if
> this wasn't addressed after Tokyo to benefit Barcelona, then it should
> be addressed now, to benefit Boston and Sydney.
>
>> This can be easily fixed by recommending the track chairs to ignore the
>> votes (even hide the results from track chair tool) and communicate
>> clearly that the crowd is not 'voting' on anything, just participating
>> in a ritual. It's a small fix to documentation and recommendations to
>> chairs.
> Which means that track chairs would have to completely guess what the
> audience might find interesting. In a community that is constantly
> growing, diversifying and spreading. Don't you think you're making the
> track chairs' work significantly more difficult that way, and more
> importantly, that this is detrimental to the quality of the tracks overall?
>
> Cheers,
> Florian
>
-- 
Best Regards,
Maish Saidel-Keesing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/community/attachments/20160518/79109e58/attachment-0001.html>