Re: Proposal to manage documentation similar to (or along with) core software.

Israel Saeta Pérez <[email protected]>
Newsgroups gmane.comp.web.zope.plone.documentation
Message-ID <[email protected]>
On 05/10/2010 12:32 PM, Dylan Jay wrote:
> hmm. sorry I think I my proposal was more confusing that it could be.
>
> I'm proposing two separate ways of dealing with versioning for the KB
> and the manuals.
>
> KB: Keep it the same, ie the way PHC does it. Each content type is
> marked with the versions it applies to. But do allow anyone with edit
> access to updating those versions so that the community can take
> responsibility for saying a howto still applies to plone version 4 for
> instance.
>
> Manuals: Create separate copies of every manual on each major plone
> release.
> For example, we move all the current manuals into a folder at
>
> http://plone.org/documentation/manual/plone3
>
> and at the time of the plone4 release we create a new folder at
>
> http://plone.org/documentation/manual/plone4
>
> and start editing those manuals independently from all the older
> plone3 versions.
>
> Pros
> ------
> - Users always know they are reading up to date documentation
> - It's very clear what to do when you want to documentation on and
> older version
> - The manuals will be simpler as we can simply remove things no longer
> relevant to older releases and we won't have to explain that certain
> things only apply to x release.
>
> Cons
> ------
> - More work if there is a correction needed in more than one major
> release. I suspect this doesn't happen often and I think it's ok to
> let old manuals go unfixed in many cases. We can't do everything. Also
> if we go with the sphnix developer manual then backporting
> documentation fixes to multiple branches is actually manageable using
> svn.


Hello,

I've been checking with other people for advice, and almost everyone 
involved in documentation thinks that branching manuals for every major 
version would result in a lot of duplicated content, since the number of 
approaches that change is tiny compared to the number of approaches that 
stay the same.

I've been updating our current documentation for Plone 4, and I can 
swear that most changes (apart from the Upgrade Guide) have involved 
just a paragraph or two, where "from Plone 4" has been indicated as 
clearly as possible. The exception has been the User Manual, where we 
have replaced all screenshots by new Sunburst ones.

Another exception was when we treated versioning (history) separately 
for Plone <3.3 and >3.3, but for this we created separate pages *inside* 
the User Manual, and that's all.

I think we can make versioning to come up organically where needed 
rather than forcing it from the start. I mean, if we see that a certain 
page contains too many "for Plone X.y, do this instead", create a new 
page for this specific version and, if a manual contains too many 
version-specific pages, branch off a new one.

IIRC Anne Botwell suggested time ago to create Kupu styles to 
differentiate stuff targeted to specific versions of Plone in a clear, 
consistent way along our documentation. Also, we can work to tag docs 
with the correct version(s) they apply to, and try to improve the way 
this info is presented to the user, so it's always clear to him/her.

And, most importantly, *work on actually improving and updating the 
documentation*. All this discussion of branching docs for major versions 
and all doesn't make any sense at all if we don't get the docs written. 
Let's get more work done and discuss less.

That said, I'm still ok with the proposal to "work towards a release" in 
docs. Establishing clear goals and timelines instead of letting 
everything exist for months as "ongoing". The work to get our 
documentation ready for Plone 3.3 and Plone 4 has turned out to be 
really effective, clearly influenced by having a specific goal and timeline.

For Plone 4 I'm working to get the following done:
- Installation guide.
- Updated videos for the Plone 4 User Manual. The manual itself is 
already published, with brand new screenshots. :)


Sorry for the long email!

-- israel


------------------------------------------------------------------------------
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.