Re: [OSGeo-Discuss] [Incubator] New incubation procedure

2015-03-15 Thread bruce.bannerman.osgeo
Hi Jachym,

I won’t be attending FOSS4GNA.


I suggest that if we are going down this track that we have and open process 
that allows all interested to provide **constructive criticism** on what people 
believe is broken.

Perhaps this could be done via the wiki.

We will then require a process to review the comments and respond 
appropriately. I suggest perhaps a weighting be added to comments from people 
who have practical experiences with the Incubation process.

This would perhaps provided the basis for determining how to move forward.


I will not have the time available to participate in this exercise, apart from 
perhaps in a review role.

I personally believe that the onus for this work should reside with those who 
believe that the current process is broken. I’m not one of these.

Bruce




On 12 Mar 2015, at 6:26 pm, Jachym Cepicky jachym.cepi...@gmail.com wrote:

 Bruce,
 
 your proposal is more then reasonable (think before you code) - I'm rather 
 thinking by coding. Very first question would be, whether more people (then 
 just me) have feeling, something in the incubation procedure as it is now 
 does not work (ergo should be fixed)?
 
 I'm speaking from my perspective (PyWPS developer, which probably never makes 
 it to incubation as it is defined now, and Board member). I want PyWPS to be 
 somehow part of OSGeo (and I believe, there are more projects like that, to 
 them is the incubation just too high step). I'm adding Jody's point to issue 
 list, I'm proposing (but it's based on previous discussions):
 
 1 - attract more projects to osgeo umbrella
 2 - attract little projects to osgeo umbrella
 3 - attract more volunteers to incubation 
 4 - define, what should happen after successful incubation, because I do not 
 believe in and lived happily ever after - to become the project, certain 
 level (checklist) has to be reached. But what if the project looses it's 
 community?
 
 Bruce: what would be your proposal to approach, in the therm of clearing 
 rationale as to what is broken? Mailing list? IRC meeting? F2F meeting (are 
 you both at FOSS4GNA?)?
 
 Thanks
 
 Jachym
 
 čt 12. 3. 2015 v 1:17 odesílatel Bruce Bannerman 
 bruce.bannerman.os...@gmail.com napsal:
 Hi Jody,
 
 The work keeps falling back on the same people…
 
 We still don’t have a clear rationale as to what is broken and what we’re 
 trying to fix.
 
 I'm inclined to not do anything until this is clearly understood.
 
 
 Bruce
 
 
 
 On Wed, Mar 11, 2015 at 11:11 AM, Jody Garnett jody.garn...@gmail.com wrote:
 I will volunteer after foss4gna to look at this.
 
 I am still interested in keeping our current procedure (as I think it is 
 producing good results) and relaxing the requirement for a mentor (which is 
 an embarrassing bottleneck).
 
 Rather than a star system I think we can highlight how far along in the 
 checklist each project is.
 
 --
 Jody Garnett
 
 On 10 March 2015 at 16:12, Bruce Bannerman bruce.bannerman.os...@gmail.com 
 wrote:
 We need to be careful when playing around with our 'Incubation Procedure'.
 
 It causes considerable angst and disruption to both mentors and to the 
 relevant communities going through incubation when we keep trying to change 
 to rules.
 
 From my opinion as a mentor, the current process while subjective in some 
 cases is still valid and effective in guiding a project to the ideals that we 
 as a community aspire to.
 
 When a project graduates from incubation, it gains considerable credibility 
 as a viable open source spatial project. It is a badge of honour for the 
 project and something to aspire too. So why are we trying to dilute this?
 
 While there are aspects that could improve, what is the rationale for wanting 
 to change the process (together with the inevitable disruption that follows)?
 
 If we are serious about changing the incubation rules, then a more formal 
 methodology such as those referred to by Cameron at [1] may be more 
 appropriate.
 
 Now, who has the spare time to investigate and drive this forward, **if we 
 deem it appropriate**.?
 
 Are there any volunteers?
 
 Bruce
 
 [1] http://lists.osgeo.org/pipermail/incubator/2015-March/002644.html 
 
 
 ===
 I recently came across a number of Open Source Maturity Methodologies, 
 which is worth being aware of, and possibly incorporating and/or 
 referencing from OSGeo Incubation processes:
 
 http://en.wikipedia.org/wiki/Open-source_software_assessment_methodologies
 
 
 
 
 
 
 
 
 
 ___
 Discuss mailing list
 Discuss@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/discuss
 
 
 ___
 Discuss mailing list
 Discuss@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/discuss

___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?

2013-05-05 Thread bruce.bannerman.osgeo
Cameron,

My personal opinion is that if this proposal was accepted, it would be a bad 
move for OGC.

Remember that OGC is a community and its Technical Committee membership are the 
people who vote on the acceptance of Standards. The TC comprises many different 
organisations.


I do understand that OGC are trying to be inclusive in their processes and to 
try and cater for alternative approaches to a problem, much the same as OSGeo 
does in supporting multiple projects that essentially handle similar use cases 
(e.g. GeoServer, MapServer and Degree).

I have also personally witnessed ESRI's commitment to helping to further the 
development of Open Spatial Standards through their work on OGC Working Groups 
and at OGC Technical Committee meetings.

ESRI also have made a valid point in their response to the 'NO' vote for the 
GeoServices REST API that the OGC has already allowed alternate approaches with 
the acceptance of netCDF as a data format and KML as a combined 
data/presentation format.

With the GeoServices REST API, I think that the approach proposed:

- is very divisive for the OGC community.
- essentially appears to propose an alternate way for working with spatial 
services that does not utilise or build on the W*S suite of services that have 
been developed through robust community processes for in excess of a decade.
- does not provide REST bindings to the W*S suite of standards that have been 
widely implemented in a range of software.
- will result in confusion within the user community that are trying to utilise 
'OGC' services.


If this approach were to be adopted, I believe that OGC will go too far down 
the alternate solution approach and will risk losing its public acceptance as 
one of the key leaders of open spatial standards.


I'm interested in hearing other OSGeo members opinions as to how this proposal 
would affect their projects.

Would you consider implementing the GeoServices REST API within your projects?

If you did, would you maintain support for both it and traditional W*S services?

Bruce

On 05/05/2013, at 7:27 AM, Cameron Shorter wrote
 OSGeo Community,
 
 Currently, voting OGC members are to decide whether to accept the 
 GeoServices REST API as an OGC standard. This is already a contentious 
 issue, with 13 votes for, and 10 votes against, 72 outstanding votes, with 
 voting halted temporally, being reopened again in a few days, and closing 2 
 weeks after that. [1]
 
 I'm wanting to hear whether people in the OSGeo community have strong 
 opinions regarding this proposed standard, and whether we as a collective 
 OSGeo community should make statements to the OGC, and voting OGC members, 
 stressing our thoughts.
 
 If there is sufficient interest, I'll raise this issue with the OSGeo Board, 
 with the intent of drafting a statement on behalf of OSGeo.
 
 As background:
 * The API was initially developed by Esri and implemented on the ArcGIS for 
 Server platform. [2]
 
 * The proposed GeoServices REST API specification overlaps with most OGC 
 standards already deployed, including: WMS, WMTS, WCS, WFS, SE/SLD, CS/W. 
 This effectively means that for most use cases covered by the GeoServices 
 REST API, applications would now have two standards to support. Also, 
 spatial infrastructure programs will be impacted, as OGC compliance won't 
 necessarily equate to interoperability.
 
 * Most (all?) current OGC web service standards to date have an Open Source 
 reference implementation, which was often (always?) part funded by OGC 
 testbeds, and open source implementations were tested against proprietary 
 implementations during OGC testbeds. As far as I'm aware, there has been 
 very little up-take from the Open Source community of the GeoServices REST 
 API, and I'm unaware of any testing of non-ESRI applications during OGC 
 testbeds. (Someone may be able to correct me here).
 
 [1] 
 https://portal.opengeospatial.org/?m=projectsa=viewproject_id=82tab=5subtab=0
 (OGC member login required. Votes counted as at 4 May 2013)
 
 [2] http://www.opengeospatial.org/standards/requests/89
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss