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

Basques, Bob (CI-StPaul) bob.basques at ci.stpaul.mn.us
Tue Dec 18 09:27:13 PST 2018

One immediate thought to stir things a bit (to this really good message BTW!!), with todays technology, why couldn’t two separate conferences be put on at the same time, with digital cross pollination of events where feasible?  Might be a future growth path actually, where region conference all happen at once or at a mimimum on an overlapping schedule of some sort.  Just thinking out loud.


On Dec 18, 2018, at 11:15 AM, Eli Adam <eadam at co.lincoln.or.us<mailto:eadam at co.lincoln.or.us>> 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<mailto:Conference_dev at lists.osgeo.org>

We’ve heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.
—Robert Wilensky

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/conference_dev/attachments/20181218/9bf0a518/attachment-0001.html>

More information about the Conference_dev mailing list