Ciao Simone, While i am not defending the process (i have given up on it) I would like to make some clarifications and corrections to your statements.
Simone Giannecchini wrote: > Ciao Andrea, > I think myself that doing everything by using JIRA is a bit unmanageable. > As an instance, let's say I am looking at the code and I find a place > where I can make a minor improvement, by, let's say, adding generics, > changing a cycle order to make it faster, adding a few more check to > improve robustness: in principle I should create jira before each of > these steps, which is IMHO more a waste of time than a useful thing > since it likes raise the bar for doing maintenance clean up, which is > the kind of work what you do when you are "playing" with the codebase. Not sure where this is coming from. Never did the process mandate that jira be made for these types of changes, although i don't see it as a bad idea though, every change having a jira makes that change trackable which imo is just good practice. > > I don't see JIRA as a way to communicate between users but rather to > collect bug reports, wishes etc. from users. The way I see this > working between us would be for very small things that do not change > semantics, just proceed, make sure tests work and then send an email > to the pseudo-maintainer to make sure he is aware and happy (and of > course revert if he is not). For larger development that is not itself > JIRA-driven (which means does not respond to a user bug > report/request) I would go with a wiki page + opening a few relevant > JIRA. This way, we (as in geoserver developers) would get away from > opening too many JIRA that will be closed in 1h by ourselves, but at > the same time we will meet communication goals using the WIKI to let > know other developers and users what we are doing, and JIRA to prevent > users from reporting bugs/entering feature request that are already > part of the WIKI page goals. It was not intended to be a tool for users, but as a tool for developers. The aggregation of jira on the Roadmap page was the high level view, and perhaps something useful to users, but never intended for that purpose. However it fell apart when it relied on people setting priorities in a consistent way. > > There is only thing about this kind of approach that makes me raise an > eyebrow, how does this relate to the GSIP thing? There might be some > duplication there both in terms of effort for the developer as well as > in documentation vs communication. The text-only wiki page describing > the goals might easily become a cut and paste of the GSIP in this > case? > > I am neutral about the idea of sending regular "what I am up to" > messages to the ml. Most part of the time, I would myself send a > message like "the same thing I was doing last week"! At the same time > I realize that this is important to let other developers know what we > are doing, but hey, we don't already do that :-)? On the other side, I > am very positive about weekly (or bi-weekly) reports about what has > been done, we could rotate and do that once per PSC memeber. The one > thing I would like add is that this should be directed more towards > users than developers, so technical things + general goals that are > trying to achieve, As a user I am more interesting in understanding, > as an instance, where we are with the hibernate catalog and with the > 2.0 release than in getting some technical insights for some problems > that some of us is addressing. It might actually be an idea to have > separate communication, quick scrum-like messages on the devel list > and longer, less frequent and more informative messages on the user > list. > > Last thing, I second Jody's annotation and I thank Justin myself for > the effort he has putting into managing releases so far. > > Ciao, > Simone. > ------------------------------------------------------- > Ing. Simone Giannecchini > GeoSolutions S.A.S. > Founder - Software Engineer > Via Carignoni 51 > 55041 Camaiore (LU) > Italy > > phone: +39 0584983027 > fax: +39 0584983027 > mob: +39 333 8128928 > > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://simboss.blogspot.com/ > http://www.linkedin.com/in/simonegiannecchini > > ------------------------------------------------------- > > > > On Wed, Sep 16, 2009 at 10:38 AM, Andrea Aime <[email protected]> wrote: >> Justin Deoliveira ha scritto: >> > So unless someone else wants to take this on I don't plan to send any >>> more road map update emails, or work for any sort of structure into the >>> short term road map. Which sort of leaves us in an undefined and >>> arbitrary state in terms of release dates. But I am sure the community >>> will figure it out as it has in the past. >> If you like I can try to take this on. But I also think I'd like to see >> it done differently. >> >> Basing all the planning just on Jira feels like micro-managing things. >> I don't see a problem with a developer putting a blocker in one >> week before the release if he's also up to fixing the blocker in time, >> and I don't really believe we can make people adjust all of the >> priorities in jira to make it become a roadmapping tool. >> >> It also feels odd that we have to push up to critical the issues >> to communicate we actually want to do them by a certain release. >> An issue might be minor by its nature but one might be finding it fun >> and work on it on a boring hour in the weekend. >> >> In general I'd prefer to see some goals set in text format instead, >> somewhere in a wiki page. This plays a lot better with major releases >> where there is a ton of jiras going on under a small number of >> wider topics and gives us an idea of what is going on without the need >> to turn each point 1-1 into a jira issue. >> >> An example of what it could look like (made up): >> >> ------------------------------------------------------------------ >> >> The 1.7.7 release is focused on bug fixing and minor new features. >> The features worked on are url mangling overhaul and map rotation. >> Link to issues fixed so far: ... >> Link to issues still scheduled: ... >> >> The 2.0-rc2 release is focused on bringing stability to the >> UI and catalog and improving the mapping abilities of the >> complex feature support, plus eventual speedup needed to compete >> in the FOSS4G benchmarking shootout. >> Link to issues fixed so far: ... >> Link to issues still scheduled: ... >> >> The following major features are being worked on but did not >> find an exact scheduling for a release: >> - hibernate catalog, by Simone and Emanuele >> - resource/publishing split >> - restconfig graduation to core >> - wps module >> - ... >> >> ----------------------------------------------------------------- >> >> Once a week we can post a summary of what happened with links >> to all the jiras closed during the week (since we get no notification >> about that), if any module moved location (graduations) >> and a check about which jiras might be blocking an >> incoming release. >> Plus we invite people to improve the release >> summary and to talk about what major new features are being >> worked on for the future. >> >> I think this would make the system more amenable to changes >> and more interesting to whoever is reading the roadmap >> page? >> >> Cheers >> Andrea >> >> -- >> Andrea Aime >> OpenGeo - http://opengeo.org >> Expert service straight from the developers. >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9-12, 2009. Register now! >> http://p.sf.net/sfu/devconf >> _______________________________________________ >> Geoserver-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >> -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
