Andrea, we raised this problem in the committee meeting. Rather than a mandatory delay, we could add an "interested parties" section to each GSIP so that those wanting to do so could advertise their desire to review pull requests for the GSIP. We could add a rule to the GSIP procedure that all subscribers listed in the "interested parties" section must be given a week (or two if requested?) to review pull requests, even after the pull request is accepted. This would allow clearer communication of interest and availability.
Kind regards, Ben. On 10/08/16 07:08, Andrea Aime wrote: > Hi, > I'm writing because I see an evident need of making a few commons sense > habits > a rule in time in which whatever is not written gets games around with > little or no consideration. > > In the GeoServer history something deemed worthy of a GSIP has been going > though the following steps: > > - Open discussion against a written proposal and vote > - Actual code development (could start earlier, but at the risk of the > one proposing the GSIP) > - Pull request and review (because accepting a plan does not equate > accepting its implementation) > > The first step has some wait time to allow the PSC to review the proposal, > it's now set to 1 week. > The last one, never had a max time to be performed, but people knew and > respected the key developers > in the area and allowed a bit of time for changes to be reviewed (the > longer, the bigger the pull request > was, with some consideration about avoiding too large pull requests at all > costs, given review is not paid). > > Unfortunately it seems that common sense and consideration have left this > community, replaced by haste and > literal rule application, so I'm proposing to add a time limit for review > of pull requests associated to > GSIPs, before automatic merge is done, in order to have some clarity and > shared understanding. > > Mimicking the proposal discussion, I'd say 1 week time, plus an extra week > in case someone > from the PSC needs extra time and explicitly asks for it. > > If there are no substantial objections I'm going to write down the proposal > in the next few days. > > Cheers > Andrea > > > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. http://sdm.link/zohodev2dev > > > > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > -- Ben Caradoc-Davies <b...@transient.nz> Director Transient Software Limited <http://transient.nz/> New Zealand ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
