And I am happy as long as the docs that have not gone through any editorial review are physically separated. I would vote to have them integrated into the User/Developer manuals because it makes sense to have that grouping. Having a single grouping for both user and developer docs will be strange.
Simone Giannecchini wrote: > On Wed, Sep 9, 2009 at 4:49 PM, Mike Pumphrey<[email protected]> wrote: >>> I don't see much of a problem with hosting pending docs. >> Okay. You mean as a separate project or as part of the User/Developer >> Manuals? (Hoping for the former...) > > As long as I can: > > - commit to a repo the work that I am doing > - let users(clients) review it online > > I am happy with what best fits your needs and/or desires. > > Ciao, > Simone. > >> Thanks, >> Mike Pumphrey >> OpenGeo - http://opengeo.org >> >> >> Justin Deoliveira wrote: >>>>> won't be built and hosted live, >>>> -1 I need me as well as others to se what I am doing. Pending, while >>>> still pending, should be visibile. I hoping to see feedback from users >>>> (and clients) more than from other members of the committer list. Or >>>> are we writing docs for ourselves? >>>> >>>>> they won't be linked to, and people are way less likely to get >>>>> confused by looking at them. >>> I don't see much of a problem with hosting pending docs. Simply by being >>> marked as pending it gets the message to users the the docs are >>> incomplete. It also serves as a motivation to the doc writers to put the >>> work into getting the docs up to quality, the equivalent of having >>> community module maintainers put in the work to get a module supported. >>>>> A la: >>>>> >>>>> User Manual (user/) >>>>> Developer Manual (developer/) >>>>> Documentation Guide (docguide/) >>>>> Pending Documentation (pending/) >>>>> >>>> +1, with the observation above. >>>> >>>> Ciao, >>>> Simone. >>>> >>>>> Please let me know if I'm confused about what's being discussed here. >>>>> >>>>> Thanks, >>>>> Mike Pumphrey >>>>> OpenGeo - http://opengeo.org >>>>> >>>>> >>>>> Justin Deoliveira wrote: >>>>>> Simone Giannecchini wrote: >>>>>>> On Tue, Sep 8, 2009 at 5:56 PM, Justin >>>>>>> Deoliveira<[email protected]> wrote: >>>>>>>> <snip> >>>>>>>>> I don't think that this way of producing docs would work at least >>>>>>>>> not for us. >>>>>>>>> 1> Working with the wiki is a real pain >>>>>>>>> 2> We often use more than on computer for our work, hence we need to >>>>>>>>> make use of svn >>>>>>>>> 3> Documentation time is expensive, we cannot afford writing on the >>>>>>>>> wiki and maintaining patches. I don't wish to put our private svn in >>>>>>>>> the loop. >>>>>>>> Excellent points. >>>>>>>> >>>>>>>>> Therefore, simple suggestion, we should think about a scheme >>>>>>>>> where the >>>>>>>>> docs get committed to svn right away and then moved into >>>>>>>>> "production-ready" documentation once a formal review has been >>>>>>>>> made (I >>>>>>>>> would add between N days). >>>>>>>>> This would make everyone happy I guess. >>>>>>>> Well branching would be the obvious answer with our current system. >>>>>>>> Although doing a full branch for working on docs is a bit of >>>>>>>> overkill. >>>>>>> I agree, overkill... >>>>>>> >>>>>>>> Another alternative could be to have a "pending" space. This could be >>>>>>>> more of a "scratch pad" type place where wiki type style writing can >>>>>>>> take place, at the same time having the docs integrated. Although >>>>>>>> pending docs would not be considered part of the finished product and >>>>>>>> stripped out of the doc artifacts when they are built. >>>>>>> This is exactly what I have in mind. Write the doc then ask for review >>>>>>> when you are ready. >>>>>> Cool. So I think the simplest way to do this would be have a pending >>>>>> directory under the top level directory. Underneath this directory we >>>>>> put pending docs. The structure could mirror the intended structure >>>>>> under the actual doc root. Examples for the recent mosaic tutorial: >>>>>> >>>>>> user/source/*pending*/tutorials/image_mosaic_plugin >>>>>> user/source/*pending*/styling/raster_symbolizer/ >>>>>> >>>>>> However this only works for new content. Patches to the existing docs >>>>>> obviously can't fall into this scheme. However those changes seem to be >>>>>> more targeted and have less content. So what about just sticking with >>>>>> the jira issue/patch/review approach given that we formalize the review >>>>>> process? >>>>>> >>>>>>>> A third answer is dsvc. >>>>>>> This is more a proposal than an answer :-) >>>>>>> >>>>>>> >>>>>>> I would say that 1 would work for the moment, 3 could be next step. >>>>>>> >>>>>>> >>>>>>> Ciao >>>>>>> Simone. >>>>>>>>> Ciao, >>>>>>>>> Simone. >>>>>>>>> >>>>>>>>> >>>>>>>>>> 2c, >>>>>>>>>> >>>>>>>>>> -Justin >>>>>>>>>> >>>>>>>>>> Mike Pumphrey wrote: >>>>>>>>>>> I don't think the idea was abandoned, but I also don't think it >>>>>>>>>>> was adopted as dogma. >>>>>>>>>>> >>>>>>>>>>> Is there a section I should take a look at and/or go in with my >>>>>>>>>>> vacuum cleaner? :) Just let me know... >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Mike Pumphrey >>>>>>>>>>> OpenGeo - http://opengeo.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Justin Deoliveira wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> Apologies if I missed something while I was away but I thought >>>>>>>>>>>> before we >>>>>>>>>>>> more or less agreed that we would adopt Mike as the user guide >>>>>>>>>>>> doc >>>>>>>>>>>> maintainer and that non-trivial changes should go through him >>>>>>>>>>>> via patches? >>>>>>>>>>>> >>>>>>>>>>>> Did we abandon that as a bad idea? >>>>>>>>>>>> >>>>>>>>>>>> -Justin >>>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>>> Let Crystal Reports handle the reporting - Free Crystal Reports >>>>>>>>>>> 2008 30-Day >>>>>>>>>>> trial. Simplify your report design, integration and deployment >>>>>>>>>>> - and focus on >>>>>>>>>>> what you do best, core application coding. Discover what's new >>>>>>>>>>> with >>>>>>>>>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>>> Let Crystal Reports handle the reporting - Free Crystal Reports >>>>>>>>>> 2008 30-Day >>>>>>>>>> trial. Simplify your report design, integration and deployment - >>>>>>>>>> and focus on >>>>>>>>>> what you do best, core application coding. Discover what's new with >>>>>>>>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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. >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> >>>>>>>> Let Crystal Reports handle the reporting - Free Crystal Reports >>>>>>>> 2008 30-Day >>>>>>>> trial. Simplify your report design, integration and deployment - >>>>>>>> and focus on >>>>>>>> what you do best, core application coding. Discover what's new with >>>>>>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>>>>>> _______________________________________________ >>>>>>>> Geoserver-devel mailing list >>>>>>>> [email protected] >>>>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> >>>>>>> Let Crystal Reports handle the reporting - Free Crystal Reports >>>>>>> 2008 30-Day >>>>>>> trial. Simplify your report design, integration and deployment - >>>>>>> and focus on >>>>>>> what you do best, core application coding. Discover what's new with >>>>>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>>>>> _______________________________________________ >>>>>>> Geoserver-devel mailing list >>>>>>> [email protected] >>>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>>> 30-Day >>>>> trial. Simplify your report design, integration and deployment - and >>>>> focus on >>>>> what you do best, core application coding. Discover what's new with >>>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>>> _______________________________________________ >>>>> Geoserver-devel mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>>>> >>> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> 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. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
