On Mon, Mar 07, 2011 at 01:08:19PM -0500, Mike Rylander wrote: > On Sun, Mar 6, 2011 at 11:36 AM, Sharp, Chris > <csh...@georgialibraries.org> wrote: > > > > > > ----- Original Message ----- > >> From: "Lori Ayre" <loria...@gmail.com> > >> To: "Dan Scott" <d...@coffeecode.net> > >> Cc: "Evergreen Discussion Group" > >> <open-ils-general@list.georgialibraries.org>, "Lori Bowen Ayre" > >> <lori.a...@galecia.com>, open-ils-documentat...@list.georgialibraries.org > >> Sent: Sunday, March 6, 2011 10:38:28 AM > > > > <snip> > > > >> > Well, IMO, documentation that institutions pay to have written for > >> > would ideally be developed as part of the community process, the > >> > same > >> > way that the software itself is developed as a community process. > >> > > >> Okay. I guess I considered what was proposed (accept the draft > >> provided as is and edit as needed) an acceptable community process. Am > >> I missing something? Are you suggesting a different workflow for > >> documenting new development? > > > > </snip> > > > > I think what Dan is saying (and I agree, if so) is that when GPLS (or > > whoever) contracts with ESI (or whomever) for documentation, that the > > process of writing the documentation is as open as the process of writing > > the software. That is, rather than having the documentation vendor work > > behind closed doors, then releasing the (mostly) finished documentation in > > one big hunk, the documentation vendor would be committing drafts, changes, > > additions, etc. all along so that the community could track it and use what > > tidbits are provided with the understanding that it is (like the software > > itself) in process, subject to change, and not ready for end users until it > > is cut and released. Dan - am I right? > >
Chris: yep, that was the idea. Thanks for expressing that with clarity and brevity :) > Speaking as ESI-the-vendor, we agree completely with the idea of > getting the documentation out earlier, including before the docs and > the features described are complete. As Chris notes indirectly, GPLS > had us work this way on this particular project, and I think we've all > (ESI, GPLS and the community) learned positively and negatively from > the process. > > We've been discussing internally the how's and wherefore's a bit today > and are developing an ESI process (and will be sharing said, so that > others may suggest improvements or duplicate good ideas) that we > believe will accomplish the goals expressed on this thread without > letting in-process documentation fall into committee-itis traps. More > on the specifics of that later, and from others than me, most likely, > but I thought it important to make sure it's understood that ESI > doesn't want to foster any sort of environment where commissioned work > leads to a "vendors vs users" feeling. We're all, individually and as > a company, committed to being just like any other community members; > that has always been our aim. Sounds good all around. Thanks for the response, Mike.
