I too can see both pros and cons to either approach. I think George's suggestion stems from a Launchpad limitation, which is that it does not allow sub-projects, as far as I can tell.
If another instance of Launchpad is created, I would like it to be for more general use, not just limited to documentation bugs specifically. E.g, web development tasks or other community needs. Also, maybe Launchpad is not an ideal tool for this sort of thing. It seems to be pretty specifically tailored for software development. So, I would say, I am very much +1 on the idea of using *some* way to keep track of non-development project needs. I think this would help in a number of areas. However, due to the nature of Launchpad, I am not persuaded that it is the best tool for that, so I am neutral on the actual proposal of using a separate Launchpad instance. That said, if a separate Launchpad instance is created, I would be likely to use it. However, I would hope that we can evaluate other options prior to deciding to go that route. Some examples: http://www.graphicrating.com/2010/05/06/10-free-project-management-tools-to-fit-your-needs/. Alexey On Sep 5, 2012, at 12:17 , Ben Shum wrote: > I'm -1 to a separate Launchpad instance if only because Evergreen's > documentation has been and is continuing to be merged into the master code of > Evergreen now. So to me, we should be tracking documentation issues in the > same place we track other aspects of Evergreen's code so that developers, > etc. are mindful of documentation-related efforts alongside their own. > > We have been using tagging to keep track of "documentation" bugs, and there > are some links (like > https://bugs.launchpad.net/evergreen/+bugs?field.tag=documentation) that > people can use to get those bugs listed out. That said, I can see how it > might be helpful for people who focus only on documentation to receive > notifications only for documentation bugs based on signing up to a dedicated > tracker. That'll keep them sane instead of having to sift through however > many normal bug announcements are published from Launchpad. > > So I guess I'm actually closer to 0 (neutral) on this proposal. > > -- Ben > > On 09/05/2012 12:57 PM, Peters, Michael wrote: >> I’d be willing to go +1 on a separate instance, if it’s not too much trouble >> to host and people are familiar with administrating it. I think it’s good >> to keep things separate. Seeing all of the software bugs could certainly be >> overwhelming if you’re only looking to help with documentation. >> >> Sincerely, >> Michael Peters >> Indiana State Library MIS | Inspire.IN.gov Helpdesk | Evergreen Indiana >> Helpdesk >> office - 317.234.2128 >> email - [email protected] >> >> From: [email protected] >> [mailto:[email protected]] On Behalf >> Of Duimovich, George >> Sent: Wednesday, September 05, 2012 12:28 PM >> To: [email protected] >> Subject: [OPEN-ILS-DOCUMENTATION] Launchpad instance >> >> >> This may have been already discussed, but I've noticed that launchpad has >> been occasionally used for website / documentation issues & gaps, in >> particular, with release or install documentation "bugs" and so on. >> >> I wonder if a *separate* launchpad instance could be effectively used by >> documentation group (say https://launchpad.net/evergreen-docs) for the >> general docs effort associated with docs.evergreen-ils.org ?. >> >> The current listserv and intermingling selected doc bugs with code bugs on >> launchpad may be working well enough, but I'm just wondering if a separate >> instance might help give better focus towards streaming tickets towards >> areas that are formally being looked after, as well as helping to identify >> gaps in documentation currently not well "owned" or edited by anyone, etc. >> >> A separate instance would still allow coders and documentation contributors >> to link to each other but maybe there's other advantages to a separate >> instance too, such as allowing developers to browse specific tickets related >> to their work? >> >> This could be especially useful for areas where organized effort is lacking >> but for which we could benefit by aggregating tickets/bugs/wishlists into >> task bundles for eventual one-shot efforts, or for volunteers acting as >> content editors for specific sections etc. So maybe we don't have a formal >> editor for this or that docs content, but a bundle of outstanding tickets >> organized / tagged for specific documentation area(s) could help a new >> volunteer (or vendor effort), as well as to help identify content areas >> lacking any sustained oversight. >> >> Or maybe launchpad or other ticketing system may be too much effort for the >> current size of the docs community? >> >> George >> >> George Duimovich >> NRCan Library / Bibliothèque de RNCan >> >> >> >> >> >> >> _______________________________________________ >> OPEN-ILS-DOCUMENTATION mailing list >> >> [email protected] >> http://list.georgialibraries.org/mailman/listinfo/open-ils-documentation > > -- > Benjamin Shum > Open Source Software Coordinator > Bibliomation, Inc. > 32 Crest Road > Middlebury, CT 06762 > 203-577-4070, ext. 113 > > _______________________________________________ > OPEN-ILS-DOCUMENTATION mailing list > [email protected] > http://list.georgialibraries.org/mailman/listinfo/open-ils-documentation Alexey Lazar PALS Information System Developer and Integrator 507-389-2907 http://www.mnpals.org/ _______________________________________________ OPEN-ILS-DOCUMENTATION mailing list [email protected] http://list.georgialibraries.org/mailman/listinfo/open-ils-documentation
