Hi all,
I also support the idea of pulling all documentation forward. Ideally,
it would be great if DIG could review everything before it was moved up,
but I think we've found that volunteers cannot always get to this in a
timely manner.
I also like Alexey's idea to identify the last time a particular piece
of documentation was reviewed.
Kathy
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
[email protected]
Twitter: http://www.twitter.com/kmlussier
On 8/9/2012 10:22 AM, Lazar, Alexey Vladimirovich wrote:
On Aug 9, 2012, at 08:50 , Dan Scott wrote:
Hi Robert:
On Thu, Aug 9, 2012 at 9:31 AM, Soulliere, Robert
<[email protected]> wrote:
Hi All,
I set up Documentation processing for Evergreen 2.3. This is in “Alpha mode”
and available for review.
It is available in the “Under Development” section of our documentation launch
page:
http://docs.evergreen-ils.org/
I also added an outline page for folks working on content to update progress on
chapters and sections:
http://www.open-ils.org/dokuwiki/doku.php?id=evergreen-docs_2.3:outline
You might notice a number of “Can this be pulled from 2.2 content?” notes in
red.
The content for those chapters are already in 2.2 and are easy to pull into
2.3. All I need is for content authors or developers who are familiar with the
content or development of the features in these chapter to indicate “yes” using
the outline or the DIG list or launchpad. Then, I can pull it in.
I'm sorry, but I don't think this is a sustainable model. I think we
have to assume that all of the 2.2 content should be pulled into 2.3,
and then deal with the exceptions as they arise. Beta-testers can open
bugs against the documentation if they find discrepancies between what
is documented and what they see in the beta release, but they can't do
that if there's no content to look at.
I would favor the idea of pulling all documentation forward. As I recently
found out, it can be a bit disorienting to have a missing section for no reason
other than it was not reviewed, even though the functionality was still there.
Perhaps as part of the Launchpad "pullrequest" and the review process,
we could start flagging areas of the documentation that need to be
changed as new features are added, or as old features are deprecated?
For clarity, perhaps all sections of the documentation could be marked with a statement
similar to "Last tested/review for version X.X.X". I think it's fair to move
documentation forward even if it may need further review or improvement, so long as
expectations are set appropriately for documentation users.
On my Utopia, no software is ever released unless it has complete and fully
tested documentation to accompany it, written in all languages. Unfortunately,
my Utopia is an imaginary place. So, let's jut go with what we have and try to
improve the documentation and processes as we can.
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
