[georss] Quick Fire Summary

[Knoth, Brian D.]

Well, I guess we'll just have to see how it works. Personally, I'm not
convinced that a pure, community vote-based mechanism is going to be a
workable solution. Maybe I'll be proven wrong (happens all the time)
but at the end of the day, work is involved in updating and publishing
the specs/schemas/etc and implementing to them. This work, in my
opinion, is better supported by a decision made by maybe 1 or 2 or 3 or
a very small committee of people who have the best interest of the
future of geoRSS at heart made-up of a cross-section of the GIS/Data
Publishers/RSS/ATOM domains. Obviously, using the voting results is
good to see the community support or non-support of a particular
enhancement, but in my opinion it should be used as a gauge only and
not as a catalyst for immediate and definite action.

That said, though, at this point any process is better then what
currently exists and I extend my gratitude to those of you who are
meeting off-line and working hard to improve it for all of us.

Regards,
brian



-----Original Message-----
From: ajturner at gmail.com [mailto:ajturner at gmail.com] On Behalf Of
Andrew Turner
Sent: Tuesday, May 01, 2007 8:13 AM
To: Christopher Schmidt
Cc: Knoth, Brian D.; georss at lists.eogeo.org
Subject: Re: [georss] Quick Fire Summary

On 5/1/07, Christopher Schmidt <crschmidt at crschmidt.net> wrote:
> On Tue, May 01, 2007 at 07:04:23AM -0400, Knoth, Brian D. wrote:
>> Do you have a minimum criteria of voting results that you
> > expect in order to seriously take action on those results? To be
> > honest, I've see about 10-15 distinct people who post to this list,
so
> > would that amount of votes carry any weight?
>
> I expect that a web-based poll would be subject to a larger
> participating audience.

There were a lot of ideas that went about, but in the end I believe we
decided that it would be a simple majority on whomever voted.
Therefore, if 7 people vote, 4 would be needed to pass.

The thought was, if you want to have a say in the standard, then vote
and it will be counted, and if you don't vote, then your opinion
doesn't count for the poll (i.e. a non-vote isn't the same as a
vote-no)

Also, we thought that even if a proposal is voted "no" it doesn't just
"go away". We understand that just because the GeoRSS community may
not like a proposal doesn't mean that your need for such a mechanism
doesn't still exist. Therefore, after a proposal is voted down, the
proposer can still document what they had to use for their
implementation (part of Raj's "code-where-your-mouth-is"), how it
worked, etc. So that other users/developers that have similar
requirements can use this "proposed standard" in their own projects.

Then, when/if the proposal comes back up for vote (more people see the
usefulness, there is a slight modification that meets more people's
happiness, etc.) and if it then passes. That proposal page can then be
used to document any migration needed from the original proposal to
the final standard. Therefore, anyone that used the proposal or their
own uses have a clear path for how to now bring it into the standard.

Does that make sense?

Andrew
_______________________________________________
georss mailing list
georss at lists.eogeo.org
http://lists.eogeo.org/mailman/listinfo/georss