[OSGeo-Conf] FOSS4G selection 2014 - consideration for new method

Jonathan Moules jonathan-lists at lightpear.com
Wed Dec 19 02:42:03 PST 2018


Hi Eli,

Excellent points you've made.

If I may add to your list of selection criteria - the obvious missing 
item to me is "conference sustainability". In my eyes the Halifax bid 
had stronger sustainability plans and ethos behind it, but the CC 
overwhelmingly voted for Calgary, which suggests this wasn't something 
that was was given much weight in the voting.

I'm hoping Calgary can take their already good start down that road and 
pick up some of the addition notions that the Halifax LoC had.

Cheers,

Jonathan


On 2018-12-18 17:15, Eli Adam wrote:
> Hi all,
>
> Given the quality of both proposals for 2020, I've been thinking a lot 
> about the best criteria to make a decision. Since about 2014 and 
> possibly before, I think that the FOSS4G selection process does not 
> serve our community or the conference as well as it could [1]. The 
> selection process may also have harmful side effects. Due to my 
> personal involvement with 2014, I'll keep most of my comments oriented 
> towards 2014 but it has been applicable to other years as well.
>
> What are valid criteria for selecting the FOSS4G LOC? The criteria I 
> personally have used are that FOSS4G is OSGeo's primary source of 
> income and thus very important. The conference should have a high 
> probability of success and low risk.  I look at the budget, how 
> reasonable I think the numbers are, and if there are any objectionable 
> contracts (usually hotel block commitments).  I look at the LOC 
> members and their experience.  I also look at the geography of past 
> conferences and value bringing FOSS4G to a new region.  Beyond that, I 
> have not been able to come up with additional selection criteria that 
> I consider valid.  What do others think?  I'd like to add to this 
> list.  Recapping the criteria, that is:
> 1) High probability of success
> 2) low risk
> 3) reasonable budget
> 4) absence of objectionable contracts
> 5) LOC experience
> 6) FOSS4G geography and history
>
> (I also have personal preferences like where I might have a free place 
> to stay, what's a cheaper travel option, who I know, etc but don't 
> consider those valid criteria. And purposely don't vote on those items.)
>
> Given those valid criteria, I often evaluate all the FOSS4G proposals 
> as extremely good.  Each having extremely high probability of success 
> and relatively low risk.  In many years, I've not really found valid 
> reasons to select one proposal over another.  I found that to be the 
> case even when I was on the LOC of one of the proposals!
>
> While a member of the 2014 LOC during the bid process, I could not 
> honestly assert that the PDX proposal was any better than the DC 
> proposal.  Obviously as a member of the PDX LOC, I was in favor of 
> ours, but that self-serving interest is not a valid basis.  Both 
> proposals would have led to great conferences with high probability of 
> success, low risk, realistic budgets, no objectionable contracts, 
> great LOC experience, and FOSS4G geography.  I've found this 
> near-equivalence of proposals to be the case in more than one 
> subsequent year.
>
> With proposals of near-equivalence, I see no point in voting and 
> selecting one.  This leads to putting two spatial centers of great 
> OSGeo and FOSS4G enthusiasm into opposition.  This competing is not 
> the typical collaborative OSGeo and FOSS4G way.  It is in fact perhaps 
> contrary to the manner in which we build software together.  With the 
> FOSS4G selection method we use now, we invariably greatly disappoint 
> one of the proposal groups. We also are creating a lot of waste and 
> wasted effort. I'd like to see a conference selection method that more 
> closely matches the collaborative spirit in which we approach other 
> endeavors.
>
> How our current selection method fails to best serve the conference or 
> our community and possible harmful side effects:
> 1. Makes something trivial overly important.
> 2. Creates divisions
> 3. Zero-sum competition (as opposed to the competition of the old WMS 
> shootouts which were beneficial to all the softwares and users of the 
> software).
> 4. Does not mirror our collaborative approach to software development 
> and other collaborative activities.
> 5. Disappoints a group and region
> 6. Fails to make use of great potential.
> 7. Does not make a better conference based on the above criteria
>
> I take FOSS4G selection more seriously than anything else that OSGeo 
> does.  FOSS4G selection is more important than anything that the Board 
> will do in the next year. OSGeo's (financial) existence depends on the 
> FOSS4G selection. Therefore I'd like us to re-examine how we make the 
> selection. I'd like to consider a new FOSS4G selection method.  Would 
> you like to see a new FOSS4G selection method?  What would that look like?
>
> This is an off-handed critique I leveled in private conversation which 
> I'll quote: "If we were a competent organization, we would recognize 
> that there is demand for TWO successful conferences in Canada.  We 
> would on the basis of costs and other advantages, select one for 2020 
> and the other for a 2021 regional conference (the 2021 "regional" 
> conference may actually be "better" by following after the other and 
> building on the enthusiasm and having another year of planning.)"  
> I've not been involved with the FOSS4GNA organizing but perhaps these 
> efforts could be harmonized in some manner?  I'm not really 
> knowledgeable on this topic, so someone knowledgeable should talk 
> about this.  While I'm straying from 2014 commentary, I'll also 
> comment that these two 2020 proposals for a North American year were 
> strikingly similar.  Both are in Canada (I would have expected at 
> least one US entry before two from Canada), both are taking the novel 
> approach of in-housing the PCO services, and both rate well on the 
> above valid criteria.
>
>
> [1] Previous thoughts about ties but similar to these thoughts. 
> https://lists.osgeo.org/pipermail/board/2014-February/006720.html
>
>
> Best regards, Eli
>
>
>
> _______________________________________________
> Conference_dev mailing list
> Conference_dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/conference_dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/conference_dev/attachments/20181219/7a448220/attachment.html>


More information about the Conference_dev mailing list