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

Paul Ramsey pramsey at cleverelephant.ca
Tue Dec 18 09:20:40 PST 2018


This is an excellent email, and I just want to put a pin in here to say
I'll be thinking about this all day and try to add to the general gist.

P.

On Tue, Dec 18, 2018 at 9:16 AM Eli Adam <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
> https://lists.osgeo.org/mailman/listinfo/conference_dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/conference_dev/attachments/20181218/9e5c3d7d/attachment.html>


More information about the Conference_dev mailing list