Helena, There are a lot of "essential part of open source projects." I think it's worth discussing what those parts are. As you noted, there are ways to improve things. I also believe it would be good to apply some metrics that help to evaluate progress. At least we should be describing (and analyzing) what works, why it works, and how it might be improved. I would like to see the history of success stories, describing what was achieved and how. This would allow others to benefit and possibly improve the process (even relish and advance the specific code).
We hear talk and words declaring success, but can we point to specifics? And even more the recipe for that success. I'm glad to 'hear' we are succeeding, but in the events you use to describe the success, I see only a lot of feel-good and self-congratulation, which is wonderful, sincerely. But there seems no description of what was produced code-wise. I think we are telling ourselves we are doing good, but I'm not sure we are doing that good. I do not doubt the sincerity or the level of effort. I'm just of the mind that it might be improved upon and possibly even better applied. More than: Agenda - What we plan to do. Note: The program is generally open for your ideas. Please edit this wiki page! Topics: 1. GRASS-QGIS interfaces: what's needed for a better GRASS GIS 7 integration 2. Interfaces to other OSGeo projects as being present in the code sprint room 3. g.extension: add gitlab+github support (maybe just a few lines in Python?) 4. ... I will try to make this my last exchange. I have, in my poor attempt, tried to carefully express what I consider worth saying. I sense this community considers what it is doing is just fine and dandy as it is, without need for any critique or introspection. So, in the words of Romeo to his lusty colleagues on their way to the dance, 'I'll be the candleholder and look on.' -Patrick -----Original Message----- From: Helena Mitasova [mailto:[email protected]] Sent: Sunday, March 6, 2016 8:49 AM To: Hogan, Patrick (ARC-PX) Cc: [email protected] Subject: Re: [OSGeo-Discuss] [Board] Funding code Sprints Patrick, as others have explained, the code or community sprints are indeed an essential part of open source projects - with developers from all over the globe, this is the opportunity to get together and get some of the important (and sometimes even critical) work done. For GRASS GIS project, we have changed the name of these events from code sprints to community sprints because we soon realized that many issues beyond coding need attention (documention, translations, website, tutorials, etc.) and that these are great for building community, new developers and students can meet the veterans of the projects and often new ideas are generated and strategic decisions made. Here are two examples of GRASS community sprints - the planning and reports of what was done: https://grasswiki.osgeo.org/wiki/GRASS_Community_Sprint_Prague_2012 https://grasswiki.osgeo.org/wiki/Talk:GRASS_Community_Sprint_Prague_2012 https://grasswiki.osgeo.org/wiki/GRASS_Community_Sprint_Como_2015 https://grasswiki.osgeo.org/wiki/Talk:GRASS_Community_Sprint_Como_2015 I hope this helps you to understand what this is all about and you are most welcome to join ane OSGeo supported code or community sprint sometime to experience it and contribute yourself - they are completely open and anybody can join, Helena > On Mar 6, 2016, at 11:15 AM, Hogan, Patrick (ARC-PX) <[email protected]> > wrote: > > Oaky, I may be misunderstanding as measured by certain specific examples. I > am very glad there are good opportunities for encouragingforward to hearing > about more of these and how well they are ‘carefully’ designed for > substantial results. > > > > I will hope the point of this dialogue is not to be right or wrong, > but to improve our methods for achieving our common goal of richer > ^commons.^ -p > > > > From: Ian Turton [mailto:[email protected]] > Sent: Sunday, March 6, 2016 7:58 AM > To: Hogan, Patrick (ARC-PX) > Cc: Andrea Aime; [email protected] > Subject: Re: [OSGeo-Discuss] [Board] Funding code Sprints > > > > Patrick, > > > > Again you are misunderstanding how sprints (at least in the GeoJava tribe) > work - we plan for weeks (or months) before hand to make the most of > theinteraction when you are 8 hours out of phase with the participants. > > > > I'd love to spend my days crafting new cathedrals but there isn't the demand > from customers for that so mostly we work at incremental improvements toback > to being gouged by proprietary suppliers who can ignore the rot and just sell > on the new shiny paint job. > > > > Ian > > > > On 6 March 2016 at 15:40, Hogan, Patrick (ARC-PX) <[email protected]> > wrote: > > Andrea, > > The world needs a more peaceful approach to the future. That’s not what we > have in a world that isstimulating drinks and high moments of constructive > exchange and recognized simpatico. > > -Patrick > > > > From: [email protected] [mailto:[email protected]] On Behalf > Of Andrea Aime > Sent: Sunday, March 6, 2016 6:32 AM > To: Hogan, Patrick (ARC-PX) > Cc: Ian Turton; [email protected] > Subject: Re: [OSGeo-Discuss] [Board] Funding code Sprints > > > > On Sun, Mar 6, 2016 at 3:18 PM, Hogan, Patrick (ARC-PX) > <[email protected]> wrote: > > It appears to me that even these more-substantial-than-hackathons sprints do > not reflect the typical work environment for code development. I willsuggest > that requires more of the 'deep thought' Leonardo approach versus the more > intuitive 'just start chiseling' of a Michelangelo. > > > > Patrick, it seems to be you imagining a work environment that's quite > different from the one a software developer in a company doing consulting > (typical open source setup) has. > > > > My normal work environment requires me to work for 2-5 different customers a > day spanning from training, spec-ing and designing new ones that I'm in > charge of. > > During a typical open source code sprint I'm focused on a single activity all > day instead. > > > > To be clear, I'm not complaining, if my daily work was single activity > I'd walk away out of boredom, what keeps the typical code sprint > > engaging is also that we normally take on activity that seem hard to > fit in the allowed time, and thus require some > > extras in terms of concentration and inventiveness to actually get > completed :-p > > > > I'd say the recipe for a typical successful open source code sprint is: > > * Several developers in the same room, that are normally working from > remote in different time zones > > * An ambitious objective (not so large/difficult that it's impossible > to complete, but enough that you cannot relax and finish it anyways) > > * Typically, full day experience (e.g., we have lunch and dinner > together too) > > * Coffee... lots of it :-p > > > > Cheers > > Andrea > > > > -- > > == > > GeoServer Professional Services from the experts! Visit > > http://goo.gl/it488V for more information. > > == > > > > Ing. Andrea Aime > > @geowolf > > Technical Lead > > > > GeoSolutions S.A.S. > Via di Montramito 3/A > 55054 Massarosa (LU) > > phone: +39 0584 962313 > > fax: +39 0584 1660272 > > mob: +39 339 8844549 > > > > http://www.geo-solutions.it > > http://twitter.com/geosolutions_it > > > > AVVERTENZE AI SENSI DEL D.Lgs. 196/2003 > > Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i > file/s allegato/i sono da considerarsi strettamente riservate. Il loro > utilizzo è consentito esclusivamente al destinatario del messaggio, per le > finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio > senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia > via e-mail e di procedere alla distruzione del messaggio stesso, > cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo > anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per > finalità diverse, costituisce comportamento contrario ai principi dettati dal > D.Lgs. 196/2003. > > > > The information in this message and/or attachments, is intended solely for > the attention and use of the named addressee(s) and may be confidential or > proprietary in nature or covered by the provisions of privacy act > (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection > Code).Any use not in accord with its purpose, any disclosure, reproduction, > copying, distribution, or either dissemination, either whole or partial, is > strictly forbidden except previous formal approval of the named addressee(s). > If you are not the intended recipient, please contact immediately the sender > by telephone, fax or e-mail and delete the information in this message that > has been received in error. The sender does not give any warranty or accept > liability as the content, accuracy or completeness of sent messages and > accepts no responsibility for changes made after they were sent or for other > risks which arise as a result of e-mail transmission, viruses, etc. > > > > ------------------------------------------------------- > > > > > > -- > > Ian Turton > > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/discuss Helena Mitasova Professor at the Department of Marine, Earth, and Atmospheric Sciences and Center for Geospatial Analytics North Carolina State University Raleigh, NC 27695-8208 [email protected] http://geospatial.ncsu.edu/osgeorel/publications.html "All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.” _______________________________________________ Discuss mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/discuss
