Discussion:
[Plone-docs] Proposal to manage documentation similar to (or along with) core software.
Alex Clark
2010-04-14 02:03:10 UTC
Permalink
Hi all,

I'm sure this has come up before but I'm wondering if it could gain some traction now.
I've been lurking in #plone-framework and I really love the proces, and daily grind
of work and activity that goes on in there. I'm wondering if we could inject some of
that enthusiasm and activity into the documentation project.

We have soooooooooo much good documentation out there, but very little structure
or organization AFAICT (and not due to lack of effort, I know people have
been working hard at various levels).

To that end, I propose we focus on the following:

0. Elect a "doc team leader" similar to the FWT leader, and have
the Plone Foundation pay a small amount to them to encourage
them to do a good job. It could even be the FWT leader, but
I doubt Eric or Hanno want the additional responsibility.
I nominate dukebody :-).

0.5. Elect a "doc team", again mirroring the FWT process here.

1. Identify all the resources we care about, e.g.:

- FAQs
- Manuals
- Plone Core Developer Reference
- Developer Manual
- Plone 2.5 User Manual
- Plone 3 User Manual
- Plone 4 User Manual
- Plone Upgrade Guide
- Add-on Products Developer Manual
- Plone Theme Reference
- PAS reference manual
- Fix for CMFEditions
- Zope Component Architecture Manual
- GenericSetup
- Error References
- Links
- Glossary
- Books
- Demonstration Movies
- Knowledge Base

2. Identify a subset to version and release.

3. Work toward a release. Ideally one that corresponds to a
software release, but I suppose that is not mandatory.

4. Have fun and profit.

5. Hang in #plone-docs 24/7.

Thoughts?

Alex
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Martin Aspeli
2010-04-14 02:08:38 UTC
Permalink
Post by Alex Clark
Hi all,
I'm sure this has come up before but I'm wondering if it could gain some traction now.
I've been lurking in #plone-framework and I really love the proces, and daily grind
of work and activity that goes on in there. I'm wondering if we could inject some of
that enthusiasm and activity into the documentation project.
We have soooooooooo much good documentation out there, but very little structure
or organization AFAICT (and not due to lack of effort, I know people have
been working hard at various levels).
0. Elect a "doc team leader" similar to the FWT leader, and have
  the Plone Foundation pay a small amount to them to encourage
  them to do a good job. It could even be the FWT leader, but
  I doubt Eric or Hanno want the additional responsibility.
  I nominate dukebody :-).
0.5. Elect a "doc team", again mirroring the FWT process here.
   - FAQs
   - Manuals
       - Plone Core Developer Reference
       - Developer Manual
       - Plone 2.5 User Manual
       - Plone 3 User Manual
       - Plone 4 User Manual
       - Plone Upgrade Guide
       - Add-on Products Developer Manual
       - Plone Theme Reference
       - PAS reference manual
       - Fix for CMFEditions
       - Zope Component Architecture Manual
       - GenericSetup
   - Error References
   - Links
   - Glossary
   - Books
   - Demonstration Movies
   - Knowledge Base
2. Identify a subset to version and release.
3. Work toward a release. Ideally one that corresponds to a
  software release, but I suppose that is not mandatory.
4. Have fun and profit.
5. Hang in #plone-docs 24/7.
+1000

In the past, the problem has normally been commitment, not process,
but I also think we've been getting a lot more mature in our
documentation approach over the last few years so this may be a
logical step.

Before you can do any of this, though, you need at least 5-10
volunteers who're willing to make a commitment similar to that the
framework team members do. That's probably a couple of hours a week,
on average.

Martin
Dylan Jay
2010-04-14 02:17:19 UTC
Permalink
Post by Martin Aspeli
Post by Alex Clark
Hi all,
I'm sure this has come up before but I'm wondering if it could gain some traction now.
I've been lurking in #plone-framework and I really love the proces, and daily grind
of work and activity that goes on in there. I'm wondering if we could inject some of
that enthusiasm and activity into the documentation project.
We have soooooooooo much good documentation out there, but very little structure
or organization AFAICT (and not due to lack of effort, I know
people have
been working hard at various levels).
0. Elect a "doc team leader" similar to the FWT leader, and have
the Plone Foundation pay a small amount to them to encourage
them to do a good job. It could even be the FWT leader, but
I doubt Eric or Hanno want the additional responsibility.
I nominate dukebody :-).
0.5. Elect a "doc team", again mirroring the FWT process here.
- FAQs
- Manuals
- Plone Core Developer Reference
- Developer Manual
- Plone 2.5 User Manual
- Plone 3 User Manual
- Plone 4 User Manual
- Plone Upgrade Guide
- Add-on Products Developer Manual
- Plone Theme Reference
- PAS reference manual
- Fix for CMFEditions
- Zope Component Architecture Manual
- GenericSetup
- Error References
- Links
- Glossary
- Books
- Demonstration Movies
- Knowledge Base
2. Identify a subset to version and release.
3. Work toward a release. Ideally one that corresponds to a
software release, but I suppose that is not mandatory.
4. Have fun and profit.
5. Hang in #plone-docs 24/7.
+1000
In the past, the problem has normally been commitment, not process,
but I also think we've been getting a lot more mature in our
documentation approach over the last few years so this may be a
logical step.
Before you can do any of this, though, you need at least 5-10
volunteers who're willing to make a commitment similar to that the
framework team members do. That's probably a couple of hours a week,
on average.
whats in those couple of hours?

I know the current/past?? organisation of the doc team has been around
"editors" and actually creating documentation, particularly now in the
manuals area. Is the suggestion that this new team be more about
making decisions rather than creating documentation?
Alex Clark
2010-04-14 18:21:51 UTC
Permalink
Post by Dylan Jay
whats in those couple of hours?
Working toward a release.
Post by Dylan Jay
I know the current/past?? organisation of the doc team has been around
"editors" and actually creating documentation, particularly now in the
manuals area. Is the suggestion that this new team be more about
making decisions rather than creating documentation?
Working toward a release. :-) It's really the same team with a more formal
structure and a target.

Dukebody, if "elected" becomes formal doc team leader, then doc team members
get selected, or elected, or whatever the FWT process is (which hannosch
has just promised to document).
Post by Dylan Jay
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Clayton Parker
2010-04-14 02:54:07 UTC
Permalink
Post by Martin Aspeli
Post by Alex Clark
Hi all,
I'm sure this has come up before but I'm wondering if it could gain some traction now.
I've been lurking in #plone-framework and I really love the proces, and daily grind
of work and activity that goes on in there. I'm wondering if we could inject some of
that enthusiasm and activity into the documentation project.
We have soooooooooo much good documentation out there, but very little structure
or organization AFAICT (and not due to lack of effort, I know people have
been working hard at various levels).
0. Elect a "doc team leader" similar to the FWT leader, and have
the Plone Foundation pay a small amount to them to encourage
them to do a good job. It could even be the FWT leader, but
I doubt Eric or Hanno want the additional responsibility.
I nominate dukebody :-).
0.5. Elect a "doc team", again mirroring the FWT process here.
- FAQs
- Manuals
- Plone Core Developer Reference
- Developer Manual
- Plone 2.5 User Manual
- Plone 3 User Manual
- Plone 4 User Manual
- Plone Upgrade Guide
- Add-on Products Developer Manual
- Plone Theme Reference
- PAS reference manual
- Fix for CMFEditions
- Zope Component Architecture Manual
- GenericSetup
- Error References
- Links
- Glossary
- Books
- Demonstration Movies
- Knowledge Base
2. Identify a subset to version and release.
3. Work toward a release. Ideally one that corresponds to a
software release, but I suppose that is not mandatory.
4. Have fun and profit.
5. Hang in #plone-docs 24/7.
+1000
In the past, the problem has normally been commitment, not process,
but I also think we've been getting a lot more mature in our
documentation approach over the last few years so this may be a
logical step.
Before you can do any of this, though, you need at least 5-10
volunteers who're willing to make a commitment similar to that the
framework team members do. That's probably a couple of hours a week,
on average.
Count me in, I enjoy writing docs. We have left a lot of things in a
half working state. It would be great to put some focus back on making
sure the Plone docs are cleaned up and working properly.

I don't necessarily think that we need to elect a "doc team" just yet,
but electing/appointing a doc team leader would be good.

Clayton
--
***@sixfeetup.com | +1 (317) 861-5948 x603
six feet up presents INDIGO : The Help Line for Plone
More info at http://sixfeetup.com/indigo or call +1 (866) 749-3338
Dylan Jay
2010-04-14 03:49:48 UTC
Permalink
Post by Clayton Parker
Post by Martin Aspeli
Post by Alex Clark
Hi all,
I'm sure this has come up before but I'm wondering if it could gain some traction now.
I've been lurking in #plone-framework and I really love the
proces, and daily grind
of work and activity that goes on in there. I'm wondering if we could inject some of
that enthusiasm and activity into the documentation project.
We have soooooooooo much good documentation out there, but very little structure
or organization AFAICT (and not due to lack of effort, I know people have
been working hard at various levels).
0. Elect a "doc team leader" similar to the FWT leader, and have
the Plone Foundation pay a small amount to them to encourage
them to do a good job. It could even be the FWT leader, but
I doubt Eric or Hanno want the additional responsibility.
I nominate dukebody :-).
0.5. Elect a "doc team", again mirroring the FWT process here.
- FAQs
- Manuals
- Plone Core Developer Reference
- Developer Manual
- Plone 2.5 User Manual
- Plone 3 User Manual
- Plone 4 User Manual
- Plone Upgrade Guide
- Add-on Products Developer Manual
- Plone Theme Reference
- PAS reference manual
- Fix for CMFEditions
- Zope Component Architecture Manual
- GenericSetup
- Error References
- Links
- Glossary
- Books
- Demonstration Movies
- Knowledge Base
2. Identify a subset to version and release.
3. Work toward a release. Ideally one that corresponds to a
software release, but I suppose that is not mandatory.
4. Have fun and profit.
5. Hang in #plone-docs 24/7.
+1000
In the past, the problem has normally been commitment, not process,
but I also think we've been getting a lot more mature in our
documentation approach over the last few years so this may be a
logical step.
Before you can do any of this, though, you need at least 5-10
volunteers who're willing to make a commitment similar to that the
framework team members do. That's probably a couple of hours a week,
on average.
Count me in, I enjoy writing docs. We have left a lot of things in a
half working state. It would be great to put some focus back on making
sure the Plone docs are cleaned up and working properly.
I don't necessarily think that we need to elect a "doc team" just yet,
but electing/appointing a doc team leader would be good.
+1 for a leader. It's not clear at all who decides and what the
process for gathering opinions is. I think maybe stevem is the leader
now?
Count me in for being part of the team but as Clayton said a clear
leader and process for now is enough.
Alex Clark
2010-04-14 18:10:50 UTC
Permalink
Post by Clayton Parker
Count me in, I enjoy writing docs. We have left a lot of things in a
half working state. It would be great to put some focus back on making
sure the Plone docs are cleaned up and working properly.
I don't necessarily think that we need to elect a "doc team" just yet,
but electing/appointing a doc team leader would be good.
Don't forget the main point: to treat documentation as software i.e. version and release it.
This is key to motivation: working towards something e.g. a release.
Post by Clayton Parker
Clayton
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Alex Clark
2010-04-14 18:05:10 UTC
Permalink
Post by Martin Aspeli
+1000
Thanks for the enthusiastic reply :-)
Post by Martin Aspeli
In the past, the problem has normally been commitment, not process,
but I also think we've been getting a lot more mature in our
documentation approach over the last few years so this may be a
logical step.
Before you can do any of this, though, you need at least 5-10
volunteers who're willing to make a commitment similar to that the
framework team members do. That's probably a couple of hours a week,
on average.
That shouldn't be too hard. What's next, pitch to the PF?
Post by Martin Aspeli
Martin
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Eric Steele
2010-04-14 02:31:52 UTC
Permalink
Post by Alex Clark
...
0. Elect a "doc team leader" similar to the FWT leader, and have
the Plone Foundation pay a small amount to them to encourage
them to do a good job. It could even be the FWT leader, but
I doubt Eric or Hanno want the additional responsibility.
I nominate dukebody :-).
Israel has been a pain in my ass over the past few months about some remaining documentation tasks assigned to me.

That, of course, means he'd be absolutely perfect for the job.

Eric
Anne Bowtell
2010-04-14 07:57:07 UTC
Permalink
I think it would be helpful to have a more clearly managed approach with
someone in charge - Israel would be great, if he were prepared to take
up the challenge. It would be good also to have a more structured,
organized approach to sprinting on documentation too, so perhaps we
could entice some more people in to the process, by setting out some
more clearly defined tasks (rather like the trac tickets, but perhaps
with more detail and guidance)*.

I drafted a kind of 'vision' for core docs once - here's the link (I'm
running for cover):

http://docs.google.com/View?id=dfrk42sj_102c3xzjxdn

I'm more than aware that we need a documentation 'process' that we can
all join in to. I'm anxious because my day job is too demanding at the
moment and I can't spare the time to do much documentation, but there's
no one to pick up the reins.

Anne


* for instance I was able to get a group of colleagues to help with
screen-shots for the user manual, by giving them access to a Plone 4
instance (rather than asking them to install Plone 4 themselves)
Post by Alex Clark
Hi all,
I'm sure this has come up before but I'm wondering if it could gain some traction now.
I've been lurking in #plone-framework and I really love the proces, and daily grind
of work and activity that goes on in there. I'm wondering if we could inject some of
that enthusiasm and activity into the documentation project.
We have soooooooooo much good documentation out there, but very little structure
or organization AFAICT (and not due to lack of effort, I know people have
been working hard at various levels).
0. Elect a "doc team leader" similar to the FWT leader, and have
the Plone Foundation pay a small amount to them to encourage
them to do a good job. It could even be the FWT leader, but
I doubt Eric or Hanno want the additional responsibility.
I nominate dukebody :-).
0.5. Elect a "doc team", again mirroring the FWT process here.
- FAQs
- Manuals
- Plone Core Developer Reference
- Developer Manual
- Plone 2.5 User Manual
- Plone 3 User Manual
- Plone 4 User Manual
- Plone Upgrade Guide
- Add-on Products Developer Manual
- Plone Theme Reference
- PAS reference manual
- Fix for CMFEditions
- Zope Component Architecture Manual
- GenericSetup
- Error References
- Links
- Glossary
- Books
- Demonstration Movies
- Knowledge Base
2. Identify a subset to version and release.
3. Work toward a release. Ideally one that corresponds to a
software release, but I suppose that is not mandatory.
4. Have fun and profit.
5. Hang in #plone-docs 24/7.
Thoughts?
Alex
Alex Clark
2010-04-14 20:49:37 UTC
Permalink
Post by Anne Bowtell
I think it would be helpful to have a more clearly managed approach with
someone in charge - Israel would be great, if he were prepared to take
up the challenge. It would be good also to have a more structured,
organized approach to sprinting on documentation too, so perhaps we
could entice some more people in to the process, by setting out some
more clearly defined tasks (rather like the trac tickets, but perhaps
with more detail and guidance)*.
I drafted a kind of 'vision' for core docs once - here's the link (I'm
http://docs.google.com/View?id=dfrk42sj_102c3xzjxdn
This is great! No need to run for cover ;-)
Post by Anne Bowtell
I'm more than aware that we need a documentation 'process' that we can
all join in to. I'm anxious because my day job is too demanding at the
moment and I can't spare the time to do much documentation, but there's
no one to pick up the reins.
Anne
* for instance I was able to get a group of colleagues to help with
screen-shots for the user manual, by giving them access to a Plone 4
instance (rather than asking them to install Plone 4 themselves)
Post by Alex Clark
Hi all,
I'm sure this has come up before but I'm wondering if it could gain some traction now.
I've been lurking in #plone-framework and I really love the proces, and daily grind
of work and activity that goes on in there. I'm wondering if we could inject some of
that enthusiasm and activity into the documentation project.
We have soooooooooo much good documentation out there, but very little structure
or organization AFAICT (and not due to lack of effort, I know people have
been working hard at various levels).
0. Elect a "doc team leader" similar to the FWT leader, and have
the Plone Foundation pay a small amount to them to encourage
them to do a good job. It could even be the FWT leader, but
I doubt Eric or Hanno want the additional responsibility.
I nominate dukebody :-).
0.5. Elect a "doc team", again mirroring the FWT process here.
- FAQs
- Manuals
- Plone Core Developer Reference
- Developer Manual
- Plone 2.5 User Manual
- Plone 3 User Manual
- Plone 4 User Manual
- Plone Upgrade Guide
- Add-on Products Developer Manual
- Plone Theme Reference
- PAS reference manual
- Fix for CMFEditions
- Zope Component Architecture Manual
- GenericSetup
- Error References
- Links
- Glossary
- Books
- Demonstration Movies
- Knowledge Base
2. Identify a subset to version and release.
3. Work toward a release. Ideally one that corresponds to a
software release, but I suppose that is not mandatory.
4. Have fun and profit.
5. Hang in #plone-docs 24/7.
Thoughts?
Alex
--------------050607080705030508000105
Content-Type: text/x-vcard; charset=utf-8;
name="anne_bowtell.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="anne_bowtell.vcf"
YmVnaW46dmNhcmQNCmZuOkFubmUgQm93dGVsbA0KbjpCb3d0ZWxsO0FubmUNCmVtYWlsO2lu
dGVybmV0OmFubmUuYm93dGVsbEBtZWRzY2kub3guYWMudWsNCnRlbDt3b3JrOis0NCAoMCkx
ODY1IDg4MjgyOQ0KeC1tb3ppbGxhLWh0bWw6RkFMU0UNCnZlcnNpb246Mi4xDQplbmQ6dmNh
cmQNCg0K
--------------050607080705030508000105
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--------------050607080705030508000105
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
--------------050607080705030508000105--
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Ricardo Newbery
2010-04-14 19:45:24 UTC
Permalink
+1

With the caveat that we should encourage a healthy rotation in the
leader role similar to what happens right now in the FWT leader role.
I also like the idea of syncing the doc release schedules more or less
with the software release schedule.

Ric
Post by Alex Clark
Hi all,
I'm sure this has come up before but I'm wondering if it could gain some traction now.
I've been lurking in #plone-framework and I really love the proces, and daily grind
of work and activity that goes on in there. I'm wondering if we could inject some of
that enthusiasm and activity into the documentation project.
We have soooooooooo much good documentation out there, but very little structure
or organization AFAICT (and not due to lack of effort, I know people have
been working hard at various levels).
0. Elect a "doc team leader" similar to the FWT leader, and have
the Plone Foundation pay a small amount to them to encourage
them to do a good job. It could even be the FWT leader, but
I doubt Eric or Hanno want the additional responsibility.
I nominate dukebody :-).
0.5. Elect a "doc team", again mirroring the FWT process here.
- FAQs
- Manuals
- Plone Core Developer Reference
- Developer Manual
- Plone 2.5 User Manual
- Plone 3 User Manual
- Plone 4 User Manual
- Plone Upgrade Guide
- Add-on Products Developer Manual
- Plone Theme Reference
- PAS reference manual
- Fix for CMFEditions
- Zope Component Architecture Manual
- GenericSetup
- Error References
- Links
- Glossary
- Books
- Demonstration Movies
- Knowledge Base
2. Identify a subset to version and release.
3. Work toward a release. Ideally one that corresponds to a
software release, but I suppose that is not mandatory.
4. Have fun and profit.
5. Hang in #plone-docs 24/7.
Thoughts?
Alex
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
Israel Saeta Pérez
2010-04-14 20:16:47 UTC
Permalink
Helloes everyone!

Part of what what you mention has already being happening, although
rather informally. Long time ago a group of "Documentation Team Editors"
was formed, mimicking the FWT, dividing the documentation into the
different sections as development, theming, managing content, etc. and
assigning one or two editors to each of them.

The members of this team were responsible of approving/rejecting
submitted documents, taking decisions about the documentation and
gardening the docs, among others
(http://plone.org/documentation/kb/plone-org-documentation-editors-roles-and-responsibilities).

Time passed by and some editors like Veda or JoAnna stepped down (see
the list of current editors at
http://plone.org/documentation/kb/documentation-team-editors). The
problem, as Martin points out, has almost always been lack of
committment due to lack of motivation and time in general. Some people
joined the Editors team and left it after short time and little work,
due to lack of motivation I guess.

I don't really know how to fight against the lack of motivation among
the people working on documentation, including me. I like to think that
lowering the contribution barrier with the division
manuals/knowledgebase will help, but with the UI work and the
policies/permissions/licenses work apparently stalled, I don't know if
we will manage to see the benefits of the knoweldgebase soon.

What I understand from Alex proposal is that he wants to formalize the
process a bit more and make it release-wise. I like the release-wise
idea, since it helps (at least in my mind) to set a clear objective
(document the next major version) and I also like the rotation idea
proposed by Ricardo Newberry, for not burning the people too much.
Post by Alex Clark
Hi all,
I'm sure this has come up before but I'm wondering if it could gain some traction now.
I've been lurking in #plone-framework and I really love the proces, and daily grind
of work and activity that goes on in there. I'm wondering if we could inject some of
that enthusiasm and activity into the documentation project.
We have soooooooooo much good documentation out there, but very little structure
or organization AFAICT (and not due to lack of effort, I know people have
been working hard at various levels).
0. Elect a "doc team leader" similar to the FWT leader, and have
the Plone Foundation pay a small amount to them to encourage
them to do a good job. It could even be the FWT leader, but
I doubt Eric or Hanno want the additional responsibility.
I nominate dukebody :-).
I've already been working on the Plone 4 documentation for some time, so
I guess I wouldn't be a bad "leader" for this release. Are we talking
about 4.0 only, or 4.x?
Post by Alex Clark
0.5. Elect a "doc team", again mirroring the FWT process here.
http://plone.org/documentation/kb/documentation-team-editors is the
current list of "doc team editors", and
http://plone.org/documentation/kb/plone-org-documentation-editors-roles-and-responsibilities
their responsabilities as stablished two years ago.
Post by Alex Clark
- FAQs
- Manuals
- Plone Core Developer Reference
- Developer Manual
...
- Knowledge Base
We care about everything and have a quite long list of more-or-less
defined tasks at https://dev.plone.org/plone/report/8 .
Post by Alex Clark
2. Identify a subset to version and release.
3. Work toward a release. Ideally one that corresponds to a
software release, but I suppose that is not mandatory.
The problem is that documentation is a kind of moving target never
finished. I cannot say "oh yeah, I've sucessfully documented portlets",
because there will always be use-cases and functions not explained. Some
parts of Plone are almost completely undocumented (e.g. some Plone 3
PLIP-based features). I don't really know how to identify a subset of
tasks and release if it isn't corresponding to a software release.
Post by Alex Clark
4. Have fun and profit.
5. Hang in #plone-docs 24/7.
This is the easy part. :)

-- israel
Anne Bowtell
2010-04-14 20:30:16 UTC
Permalink
Post by Israel Saeta Pérez
The problem is that documentation is a kind of moving target never
finished. I cannot say "oh yeah, I've sucessfully documented portlets",
because there will always be use-cases and functions not explained.
I agree - plus we're running to keep up with core docs not yet finished
and Plone 4 around the corner. Breaking things down into even smaller
parts would really help - as the scale of the task is sometimes
completely overwhelming and it can be hard to make progress.

Anne
JoAnna Springsteen
2010-04-14 20:49:23 UTC
Permalink
Excellent summary Israel!

What aclark has proposed is really nothing new. We've been talking
about doing this since the google doc sprint in 2007. The goal for the
past few years has always been to release up to date docs when a new
release of Plone is sent out.
The key issue here is getting people to commit to volunteering and
then ensuring they follow through with their committments. 1-2 hours a
week is an under-estimate of the effort required. Documentation is
time intensive and it will always be a moving target, as Israel
mentions.
A lesson learned to keep in mind is that no matter what plans you make
or how much you formalize the process, if you can't get people to
follow through on what they say they will do, you can't make progress.


j.
Alex Clark
2010-04-14 23:30:39 UTC
Permalink
Post by JoAnna Springsteen
Excellent summary Israel!
What aclark has proposed is really nothing new. We've been talking
about doing this since the google doc sprint in 2007. The goal for the
past few years has always been to release up to date docs when a new
release of Plone is sent out.
Right, but up to date docs != versioning. We have not *versioned* and
*released* docs to date. That needs to start happening now with Plone 4 IMO,
so that by the time Plone 5 rolls around we can look back and say
"Ahhhh, these are the docs we shipped with Plone 4".
Post by JoAnna Springsteen
The key issue here is getting people to commit to volunteering and
then ensuring they follow through with their committments.
1-2 hours a
week is an under-estimate of the effort required. Documentation is
time intensive and it will always be a moving target, as Israel
mentions.
A lesson learned to keep in mind is that no matter what plans you make
or how much you formalize the process, if you can't get people to
follow through on what they say they will do, you can't make progress.
Pay the release manager and the doc team will either deliver, or suffer
the consequences. ;-)
Post by JoAnna Springsteen
j.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Dylan Jay
2010-04-15 00:05:16 UTC
Permalink
Post by Alex Clark
Post by JoAnna Springsteen
Excellent summary Israel!
What aclark has proposed is really nothing new. We've been talking
about doing this since the google doc sprint in 2007. The goal for the
past few years has always been to release up to date docs when a new
release of Plone is sent out.
Right, but up to date docs != versioning. We have not *versioned* and
*released* docs to date. That needs to start happening now with Plone 4 IMO,
so that by the time Plone 5 rolls around we can look back and say
"Ahhhh, these are the docs we shipped with Plone 4".
+10. All the manuals should have separate versions viewable with urls
that clearly state the major plone version to which it belongs. If
that means we no longer improve the plone3 user guide after plone 4
comes out I think thats fine IMO. I don't know if versioning is built
into the new proposed UI for the manuals section.
I can;t see how KB content is going to be practical to have separate
versions so I guess it will have to keep the existing way of stating
which versions of plone the doc was written for.
Post by Alex Clark
Post by JoAnna Springsteen
The key issue here is getting people to commit to volunteering and
then ensuring they follow through with their committments.
1-2 hours a
week is an under-estimate of the effort required. Documentation is
time intensive and it will always be a moving target, as Israel
mentions.
A lesson learned to keep in mind is that no matter what plans you make
or how much you formalize the process, if you can't get people to
follow through on what they say they will do, you can't make
progress.
Pay the release manager and the doc team will either deliver, or suffer
the consequences. ;-)
+1 to paying the release manager. It's a stressful job. But are you
sure it should be the same person making decisions? for example
deciding that we need to concentrate on portlets documentation vs
workflow documentation on the plone 4 release? or deciding if we
should use the sphinx developer manual vs the current one in
plone.org? Is the release manager the right person for that job? it
seems to me the qualities of the enforcer vs the decision maker are
very different.
Post by Alex Clark
Post by JoAnna Springsteen
j.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
Alex Clark
2010-04-15 00:51:50 UTC
Permalink
Post by Dylan Jay
+10. All the manuals should have separate versions viewable with urls
that clearly state the major plone version to which it belongs. If
that means we no longer improve the plone3 user guide after plone 4
comes out I think thats fine IMO. I don't know if versioning is built
into the new proposed UI for the manuals section.
I can;t see how KB content is going to be practical to have separate
versions so I guess it will have to keep the existing way of stating
which versions of plone the doc was written for.
There is the PHC notion of version, which has not proven to be too
useful over the years.
Post by Dylan Jay
+1 to paying the release manager. It's a stressful job. But are you
sure it should be the same person making decisions?
Yes :-)
Post by Dylan Jay
for example
deciding that we need to concentrate on portlets documentation vs
workflow documentation on the plone 4 release? or deciding if we
should use the sphinx developer manual vs the current one in
plone.org? Is the release manager the right person for that job? it
seems to me the qualities of the enforcer vs the decision maker are
very different.
It's a collaborative effort. The release manager relies on
the expertise and advice of doc team members, but ultimately has
final say.
Post by Dylan Jay
Post by Alex Clark
Post by Martin Aspeli
j.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Mikko Ohtamaa
2010-04-19 08:35:46 UTC
Permalink
Post by Alex Clark
Right, but up to date docs != versioning. We have not *versioned* and
*released* docs to date. That needs to start happening now with Plone 4 IMO,
so that by the time Plone 5 rolls around we can look back and say
"Ahhhh, these are the docs we shipped with Plone 4".
This is very good idea. However I think the train for Plone 4 has already
left and it would be more realistic to target with versioned docs to Plone
5.

E.g.

* Create a place for Plone 5 documentation when the development process is
kicked off

* Populate this place from docs from plone.org doc area

* Make sure every doc is updated regarding Plone 5 - e.g. a workflow with
"Plone 5 approved" switch

* Release

... or ...

* Have a collection, or collection of collections, which will pick up Plone
5 docs from docarea mass

Too complex?


-----
Mikko Ohtamaa
mFabrik - Freedom Delivered.

Web site - http://mfabrik.com
Mobile site - http://mfabrik.mobi
Blog - http://blog.mfabrik.com
--
View this message in context: http://n2.nabble.com/Proposal-to-manage-documentation-similar-to-or-along-with-core-software-tp4899546p4924106.html
Sent from the Documentation Team mailing list archive at Nabble.com.
Alex Clark
2010-04-21 01:08:24 UTC
Permalink
Hi Moo,
Post by Mikko Ohtamaa
This is very good idea.
Thanks!
Post by Mikko Ohtamaa
However I think the train for Plone 4 has already
left and it would be more realistic to target with versioned docs to Plone
5.
How about 4.1 ? :-)
Post by Mikko Ohtamaa
E.g.
* Create a place for Plone 5 documentation when the development process is
kicked off
* Populate this place from docs from plone.org doc area
* Make sure every doc is updated regarding Plone 5 - e.g. a workflow with
"Plone 5 approved" switch
* Release
Yes! This is close. In particular I like the "create a place" and "populate
from plone.org docs" pieces. Not as sure about the wf piece, though it may
work ok and/or be reasonable.
Post by Mikko Ohtamaa
... or ...
* Have a collection, or collection of collections, which will pick up Plone
5 docs from docarea mass
Maybe. I tend to shy away when "using Plone" becomes part of the documentation
process, but maybe that's just me.
Post by Mikko Ohtamaa
Too complex?
Not IMO. I think you got the gist of my points. And I think it's all attainable.
Post by Mikko Ohtamaa
-----
Mikko Ohtamaa
mFabrik - Freedom Delivered.
Web site - http://mfabrik.com
Mobile site - http://mfabrik.mobi
Blog - http://blog.mfabrik.com
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Dylan Jay
2010-04-14 21:29:26 UTC
Permalink
So whose job is it to prod those finishing the changes to the kb ui?
The editors team is great but it isn't the same as the fwt beacause
they just review instead of do the work themselves. So if we are to
model ourselves on the fwt process what do we need?
What we need most is release manager for docs. This is something
joanna was fantastic at and will be sorely missed for. A cat herder
and finder of volenteers. Not someone to set the vision but to enforce
it.
Secondly I think we need a person or team with vision and authority to
make decions about which proposal to go with so there is a clear
direction. Thats what a leader does, listens to everyone and takes
responsibilty for the decision. This is the equivilent to the fwt I
think. I think in the past we may have confused the team doing the
work with the team making decisions. It's hard to have vision when you
feel like your the only one who is going to do it ;).

Dylan Jay
Technical solution manager
PretaWeb 99552830
Post by Israel Saeta Pérez
Helloes everyone!
Part of what what you mention has already being happening, although
rather informally. Long time ago a group of "Documentation Team Editors"
was formed, mimicking the FWT, dividing the documentation into the
different sections as development, theming, managing content, etc. and
assigning one or two editors to each of them.
The members of this team were responsible of approving/rejecting
submitted documents, taking decisions about the documentation and
gardening the docs, among others
(http://plone.org/documentation/kb/plone-org-documentation-editors-roles-and-responsibilities
).
Time passed by and some editors like Veda or JoAnna stepped down (see
the list of current editors at
http://plone.org/documentation/kb/documentation-team-editors). The
problem, as Martin points out, has almost always been lack of
committment due to lack of motivation and time in general. Some people
joined the Editors team and left it after short time and little work,
due to lack of motivation I guess.
I don't really know how to fight against the lack of motivation among
the people working on documentation, including me. I like to think that
lowering the contribution barrier with the division
manuals/knowledgebase will help, but with the UI work and the
policies/permissions/licenses work apparently stalled, I don't know if
we will manage to see the benefits of the knoweldgebase soon.
What I understand from Alex proposal is that he wants to formalize the
process a bit more and make it release-wise. I like the release-wise
idea, since it helps (at least in my mind) to set a clear objective
(document the next major version) and I also like the rotation idea
proposed by Ricardo Newberry, for not burning the people too much.
Post by Alex Clark
Hi all,
I'm sure this has come up before but I'm wondering if it could gain some traction now.
I've been lurking in #plone-framework and I really love the proces, and daily grind
of work and activity that goes on in there. I'm wondering if we could inject some of
that enthusiasm and activity into the documentation project.
We have soooooooooo much good documentation out there, but very little structure
or organization AFAICT (and not due to lack of effort, I know
people have
been working hard at various levels).
0. Elect a "doc team leader" similar to the FWT leader, and have
the Plone Foundation pay a small amount to them to encourage
them to do a good job. It could even be the FWT leader, but
I doubt Eric or Hanno want the additional responsibility.
I nominate dukebody :-).
I've already been working on the Plone 4 documentation for some time, so
I guess I wouldn't be a bad "leader" for this release. Are we talking
about 4.0 only, or 4.x?
Post by Alex Clark
0.5. Elect a "doc team", again mirroring the FWT process here.
http://plone.org/documentation/kb/documentation-team-editors is the
current list of "doc team editors", and
http://plone.org/documentation/kb/plone-org-documentation-editors-roles-and-responsibilities
their responsabilities as stablished two years ago.
Post by Alex Clark
- FAQs
- Manuals
- Plone Core Developer Reference
- Developer Manual
...
- Knowledge Base
We care about everything and have a quite long list of more-or-less
defined tasks at https://dev.plone.org/plone/report/8 .
Post by Alex Clark
2. Identify a subset to version and release.
3. Work toward a release. Ideally one that corresponds to a
software release, but I suppose that is not mandatory.
The problem is that documentation is a kind of moving target never
finished. I cannot say "oh yeah, I've sucessfully documented
portlets",
because there will always be use-cases and functions not explained. Some
parts of Plone are almost completely undocumented (e.g. some Plone 3
PLIP-based features). I don't really know how to identify a subset of
tasks and release if it isn't corresponding to a software release.
Post by Alex Clark
4. Have fun and profit.
5. Hang in #plone-docs 24/7.
This is the easy part. :)
-- israel
---
---
---
---------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
Clayton Parker
2010-04-14 22:50:00 UTC
Permalink
Post by Dylan Jay
So whose job is it to prod those finishing the changes to the kb ui?
The editors team is great but it isn't the same as the fwt beacause
they just review instead of do the work themselves. So if we are to
model ourselves on the fwt process what do we need?
What we need most is release manager for docs. This is something
joanna was fantastic at and will be sorely missed for. A cat herder
and finder of volenteers. Not someone to set the vision but to enforce
it.
+1, as mentioned time and again, the biggest issue is the time
commitment. We need someone to be the official cat herder!
Post by Dylan Jay
Secondly I think we need a person or team with vision and authority to
make decions about which proposal to go with so there is a clear
direction. Thats what a leader does, listens to everyone and takes
responsibilty for the decision. This is the equivilent to the fwt I
think. I think in the past we may have confused the team doing the
work with the team making decisions. It's hard to have vision when you
feel like your the only one who is going to do it ;).
That's a good point, I was thinking that the appointed/elected would
have to do the work. Either way we still need to make the day have more
hours in it ;)

Clayton
--
***@sixfeetup.com | +1 (317) 861-5948 x603
six feet up presents INDIGO : The Help Line for Plone
More info at http://sixfeetup.com/indigo or call +1 (866) 749-3338
Post by Dylan Jay
Post by Israel Saeta Pérez
Helloes everyone!
Part of what what you mention has already being happening, although
rather informally. Long time ago a group of "Documentation Team Editors"
was formed, mimicking the FWT, dividing the documentation into the
different sections as development, theming, managing content, etc. and
assigning one or two editors to each of them.
The members of this team were responsible of approving/rejecting
submitted documents, taking decisions about the documentation and
gardening the docs, among others
(http://plone.org/documentation/kb/plone-org-documentation-editors-roles-and-responsibilities
).
Time passed by and some editors like Veda or JoAnna stepped down (see
the list of current editors at
http://plone.org/documentation/kb/documentation-team-editors). The
problem, as Martin points out, has almost always been lack of
committment due to lack of motivation and time in general. Some people
joined the Editors team and left it after short time and little work,
due to lack of motivation I guess.
I don't really know how to fight against the lack of motivation among
the people working on documentation, including me. I like to think that
lowering the contribution barrier with the division
manuals/knowledgebase will help, but with the UI work and the
policies/permissions/licenses work apparently stalled, I don't know if
we will manage to see the benefits of the knoweldgebase soon.
What I understand from Alex proposal is that he wants to formalize the
process a bit more and make it release-wise. I like the release-wise
idea, since it helps (at least in my mind) to set a clear objective
(document the next major version) and I also like the rotation idea
proposed by Ricardo Newberry, for not burning the people too much.
Post by Alex Clark
Hi all,
I'm sure this has come up before but I'm wondering if it could gain some traction now.
I've been lurking in #plone-framework and I really love the proces, and daily grind
of work and activity that goes on in there. I'm wondering if we could inject some of
that enthusiasm and activity into the documentation project.
We have soooooooooo much good documentation out there, but very little structure
or organization AFAICT (and not due to lack of effort, I know people have
been working hard at various levels).
0. Elect a "doc team leader" similar to the FWT leader, and have
the Plone Foundation pay a small amount to them to encourage
them to do a good job. It could even be the FWT leader, but
I doubt Eric or Hanno want the additional responsibility.
I nominate dukebody :-).
I've already been working on the Plone 4 documentation for some time, so
I guess I wouldn't be a bad "leader" for this release. Are we talking
about 4.0 only, or 4.x?
Post by Alex Clark
0.5. Elect a "doc team", again mirroring the FWT process here.
http://plone.org/documentation/kb/documentation-team-editors is the
current list of "doc team editors", and
http://plone.org/documentation/kb/plone-org-documentation-editors-roles-and-responsibilities
their responsabilities as stablished two years ago.
Post by Alex Clark
- FAQs
- Manuals
- Plone Core Developer Reference
- Developer Manual
...
- Knowledge Base
We care about everything and have a quite long list of more-or-less
defined tasks at https://dev.plone.org/plone/report/8 .
Post by Alex Clark
2. Identify a subset to version and release.
3. Work toward a release. Ideally one that corresponds to a
software release, but I suppose that is not mandatory.
The problem is that documentation is a kind of moving target never
finished. I cannot say "oh yeah, I've sucessfully documented
portlets",
because there will always be use-cases and functions not explained. Some
parts of Plone are almost completely undocumented (e.g. some Plone 3
PLIP-based features). I don't really know how to identify a subset of
tasks and release if it isn't corresponding to a software release.
Post by Alex Clark
4. Have fun and profit.
5. Hang in #plone-docs 24/7.
This is the easy part. :)
-- israel
---
---
---
---------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
Alex Clark
2010-04-14 23:20:16 UTC
Permalink
Post by Dylan Jay
So whose job is it to prod those finishing the changes to the kb ui?
Not the doc team's problem, IMO. The doc team should write and release docs, period.
When a release is ready, it should be published to plone.org. If there are
problems doing that, then it's the website team's responsibility to fix it.
This is not unlike the core software / installer dance.
Post by Dylan Jay
The editors team is great but it isn't the same as the fwt beacause
they just review instead of do the work themselves. So if we are to
model ourselves on the fwt process what do we need?
What we need most is release manager for docs. This is something
joanna was fantastic at and will be sorely missed for. A cat herder
and finder of volenteers. Not someone to set the vision but to enforce
it.
Secondly I think we need a person or team with vision and authority to
make decions about which proposal to go with so there is a clear
direction. Thats what a leader does, listens to everyone and takes
responsibilty for the decision. This is the equivilent to the fwt I
think. I think in the past we may have confused the team doing the
work with the team making decisions. It's hard to have vision when you
feel like your the only one who is going to do it ;).
Yup, the Doc team leader sets the release date, work schedule,
deliverables, etc. and then enforces them. What's needed now IMO
is to get foundation buy-in on paying the doc team leader.
Post by Dylan Jay
Dylan Jay
Technical solution manager
PretaWeb 99552830
Post by Israel Saeta Pérez
Helloes everyone!
Part of what what you mention has already being happening, although
rather informally. Long time ago a group of "Documentation Team Editors"
was formed, mimicking the FWT, dividing the documentation into the
different sections as development, theming, managing content, etc. and
assigning one or two editors to each of them.
The members of this team were responsible of approving/rejecting
submitted documents, taking decisions about the documentation and
gardening the docs, among others
(http://plone.org/documentation/kb/plone-org-documentation-editors-roles-and-responsibilities
).
Time passed by and some editors like Veda or JoAnna stepped down (see
the list of current editors at
http://plone.org/documentation/kb/documentation-team-editors). The
problem, as Martin points out, has almost always been lack of
committment due to lack of motivation and time in general. Some people
joined the Editors team and left it after short time and little work,
due to lack of motivation I guess.
I don't really know how to fight against the lack of motivation among
the people working on documentation, including me. I like to think that
lowering the contribution barrier with the division
manuals/knowledgebase will help, but with the UI work and the
policies/permissions/licenses work apparently stalled, I don't know if
we will manage to see the benefits of the knoweldgebase soon.
What I understand from Alex proposal is that he wants to formalize the
process a bit more and make it release-wise. I like the release-wise
idea, since it helps (at least in my mind) to set a clear objective
(document the next major version) and I also like the rotation idea
proposed by Ricardo Newberry, for not burning the people too much.
Post by Alex Clark
Hi all,
I'm sure this has come up before but I'm wondering if it could gain some traction now.
I've been lurking in #plone-framework and I really love the proces, and daily grind
of work and activity that goes on in there. I'm wondering if we could inject some of
that enthusiasm and activity into the documentation project.
We have soooooooooo much good documentation out there, but very little structure
or organization AFAICT (and not due to lack of effort, I know people have
been working hard at various levels).
0. Elect a "doc team leader" similar to the FWT leader, and have
the Plone Foundation pay a small amount to them to encourage
them to do a good job. It could even be the FWT leader, but
I doubt Eric or Hanno want the additional responsibility.
I nominate dukebody :-).
I've already been working on the Plone 4 documentation for some time, so
I guess I wouldn't be a bad "leader" for this release. Are we talking
about 4.0 only, or 4.x?
Post by Alex Clark
0.5. Elect a "doc team", again mirroring the FWT process here.
http://plone.org/documentation/kb/documentation-team-editors is the
current list of "doc team editors", and
http://plone.org/documentation/kb/plone-org-documentation-editors-roles-and-responsibilities
their responsabilities as stablished two years ago.
Post by Alex Clark
- FAQs
- Manuals
- Plone Core Developer Reference
- Developer Manual
...
- Knowledge Base
We care about everything and have a quite long list of more-or-less
defined tasks at https://dev.plone.org/plone/report/8 .
Post by Alex Clark
2. Identify a subset to version and release.
3. Work toward a release. Ideally one that corresponds to a
software release, but I suppose that is not mandatory.
The problem is that documentation is a kind of moving target never
finished. I cannot say "oh yeah, I've sucessfully documented
portlets",
because there will always be use-cases and functions not explained. Some
parts of Plone are almost completely undocumented (e.g. some Plone 3
PLIP-based features). I don't really know how to identify a subset of
tasks and release if it isn't corresponding to a software release.
Post by Alex Clark
4. Have fun and profit.
5. Hang in #plone-docs 24/7.
This is the easy part. :)
-- israel
---
---
---
---------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Alexander Limi
2010-04-15 07:24:03 UTC
Permalink
Post by Dylan Jay
So whose job is it to prod those finishing the changes to the kb ui?
That's on me, and I want to finish it this weekend when we work on the Plone
4 feature documentation/overview.

I'm going to be prioritizing the typical top level I-just-discovered-Plone
cases in preparation for the Plone 4 release, which essentially means:

- Plone 4 overview and feature list
- Better front page that sells Plone 4 in particular, and Plone in
general (but that last part will take a bit longer and we'll focus on Plone
4 first)
- Better docs front page, and optimize flow to make it easy to:
- Get started
- Contribute back to the KB
- Better Support page with simpler choices (essentially:
mailinglist/forum | chatroom | commercial support | training)

Am I missing anything that you think newcomers would be confused by?

I like the idea of choosing a "documentation lead" on a per-major-release
basis similar to the Framework Team process, with the option to switch along
the way, e.g. at 4.3 release.
--
Alexander Limi · http://limi.net
Alex Clark
2010-04-14 23:48:08 UTC
Permalink
Post by Israel Saeta Pérez
I don't really know how to fight against the lack of motivation among
the people working on documentation, including me.
Do you like getting paid? That is what I am proposing. I don't know
the likelyhood that the PF will buy into this, but it would seed
a lot of activity I think.
Post by Israel Saeta Pérez
I like to think that
lowering the contribution barrier with the division
manuals/knowledgebase will help, but with the UI work and the
policies/permissions/licenses work apparently stalled, I don't know if
we will manage to see the benefits of the knoweldgebase soon.
Me neither, and I hate stalls. Find a way to work around it, would be
my suggestion.
Post by Israel Saeta Pérez
I've already been working on the Plone 4 documentation for some time, so
I guess I wouldn't be a bad "leader" for this release. Are we talking
about 4.0 only, or 4.x?
4.x
Post by Israel Saeta Pérez
Post by Alex Clark
0.5. Elect a "doc team", again mirroring the FWT process here.
http://plone.org/documentation/kb/documentation-team-editors is the
current list of "doc team editors", and
http://plone.org/documentation/kb/plone-org-documentation-editors-roles-and-responsibilities
their responsabilities as stablished two years ago.
This reads a bit dated to me, and in fact it says
"This scheme will be replaced in a close future by manual owners. ".

How about this: With each release, the new doc team leader and members decide
their roles, and accounce them to the community.

*shrug*

I don't know much about how this works within the FWT, just that
everyone owns something and collectively, eventually, their work
forms a release.
Post by Israel Saeta Pérez
We care about everything and have a quite long list of more-or-less
defined tasks at https://dev.plone.org/plone/report/8 .
The most important thing I can think of is end-user documentation,
followed by "integrator" documentation. Developers, at least for now
can figure it out themselves ;-) (Well, not really but just trying to
prioritize).

Maybe installation docs, too.
Post by Israel Saeta Pérez
finished. I cannot say "oh yeah, I've sucessfully documented portlets",
because there will always be use-cases and functions not explained. Some
parts of Plone are almost completely undocumented (e.g. some Plone 3
PLIP-based features). I don't really know how to identify a subset of
tasks and release if it isn't corresponding to a software release.
Work towards a release. :-) There is only so much to be said about portlets
in a Plone 4 end user manual. The marketing peeps already cover "What's new?"
AFAIK.
Post by Israel Saeta Pérez
Post by Alex Clark
4. Have fun and profit.
5. Hang in #plone-docs 24/7.
This is the easy part. :)
-- israel
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Israel Saeta Pérez
2010-04-15 07:20:43 UTC
Permalink
Post by Alex Clark
Post by Israel Saeta Pérez
I don't really know how to fight against the lack of motivation among
the people working on documentation, including me.
Do you like getting paid? That is what I am proposing. I don't know
the likelyhood that the PF will buy into this, but it would seed
a lot of activity I think.
Yes I like getting paid, but I don't know why I've always been less
hesitating to contribute to unpaid projects. Perhaps because accepting a
payment means real committing and a lot of responsability.
Post by Alex Clark
Post by Israel Saeta Pérez
I like to think that
lowering the contribution barrier with the division
manuals/knowledgebase will help, but with the UI work and the
policies/permissions/licenses work apparently stalled, I don't know if
we will manage to see the benefits of the knoweldgebase soon.
Me neither, and I hate stalls. Find a way to work around it, would be
my suggestion.
I'm already approving every document which is submitted for review to
the KB. I need to talk to Steve McMahon about the permission settings in
the KB.

[...]
Post by Alex Clark
Post by Israel Saeta Pérez
Post by Alex Clark
0.5. Elect a "doc team", again mirroring the FWT process here.
http://plone.org/documentation/kb/documentation-team-editors is the
current list of "doc team editors", and
http://plone.org/documentation/kb/plone-org-documentation-editors-roles-and-responsibilities
their responsabilities as stablished two years ago.
This reads a bit dated to me, and in fact it says
"This scheme will be replaced in a close future by manual owners. ".
I guess this was written by Veda or Steve when we decided for the
division manuals/kb, so instead of section owners, we would have manual
owners (what wouldn't be sooo different anyhow).
Post by Alex Clark
How about this: With each release, the new doc team leader and members decide
their roles, and accounce them to the community.
*shrug*
Sounds good but, as Martin points out, you need a bunch of people
willing to commit. Currently, the doc-team editors are the ones who have
committed to a similar task, but we've had more people stepping down
than working hard.

I assume part of the responsability (for the people not working hard)
because I know I've not leveled the way of the people who could do the
work as much as I could. Lazy, bad-structured procrastinator Israel. :P
Post by Alex Clark
I don't know much about how this works within the FWT, just that
everyone owns something and collectively, eventually, their work
forms a release.
If I didn't get it wrong, the work of the FWT is to vote PLIPs, not to
work on implementing them. The last is the task of the implementor.
Post by Alex Clark
Post by Israel Saeta Pérez
We care about everything and have a quite long list of more-or-less
defined tasks at https://dev.plone.org/plone/report/8 .
The most important thing I can think of is end-user documentation,
followed by "integrator" documentation. Developers, at least for now
can figure it out themselves ;-) (Well, not really but just trying to
prioritize).
We've already started to take screenshots for the Plone 4 User Manual,
with the help of a very productive group of folks summonned by Anne
Botwell. ;)
Post by Alex Clark
Maybe installation docs, too.
Yep, https://dev.plone.org/plone/ticket/9080 .
Post by Alex Clark
Post by Israel Saeta Pérez
finished. I cannot say "oh yeah, I've sucessfully documented portlets",
because there will always be use-cases and functions not explained. Some
parts of Plone are almost completely undocumented (e.g. some Plone 3
PLIP-based features). I don't really know how to identify a subset of
tasks and release if it isn't corresponding to a software release.
Work towards a release. :-) There is only so much to be said about portlets
in a Plone 4 end user manual. The marketing peeps already cover "What's new?"
AFAIK.
Well, I guess we could make the manuals release-wise and leave the KB
unversioned. Django has release-wise documentation and everybody likes
the Django docs. We can "experiment" with this approach.

But there are some problems assocciated:

1) If there's wrong info/errata in a manual, we would have to fix it in
all versions/releases, what is tedious. Are we talking about a manual
for each X.y version or just for X?

2) We don't have the necessary PHC infrastructure and UI to present the
different versions of the manuals to the users. We could create a folder
for each version and copy-paste items to work on new releases, but I
don't know how to present this properly in the UI.

-- israel
Felipe Roquette
2010-04-15 13:02:03 UTC
Permalink
Hello all!

On Thu, 15 Apr 2010 09:20:43 +0200, Israel Saeta Pérez
Post by Israel Saeta Pérez
Post by Alex Clark
Post by Israel Saeta Pérez
I don't really know how to fight against the lack of motivation among
the people working on documentation, including me.
Do you like getting paid? That is what I am proposing. I don't know
the likelyhood that the PF will buy into this, but it would seed
a lot of activity I think.
Yes I like getting paid, but I don't know why I've always been less
hesitating to contribute to unpaid projects. Perhaps because accepting a
payment means real committing and a lot of responsability.
What I am going to write is little of topic, but I think it is important
to the people who decides that kind of things.
I always like to incentive people to be motivated and I'm always studying
this subject. Right now I reading Drive (wrote by Daniel Pink).
I its very interesting what he points out on his book: there are some
studies (from Universities) that proves that business is doing the wrong
way. Business give money to motivate people and that way you can get the
opposite effect.
If someone is interested, fill free to contact me.

Thanks for everyone, Plone (including the community) is incredible :),
--
Felipe Roquette
***@krei.com.br

www.krei.com.br
+55 11 3431.0303
Ricardo Newbery
2010-04-15 17:25:51 UTC
Permalink
Post by Felipe Roquette
Hello all!
On Thu, 15 Apr 2010 09:20:43 +0200, Israel Saeta Pérez
Post by Israel Saeta Pérez
Post by Alex Clark
Post by Israel Saeta Pérez
I don't really know how to fight against the lack of motivation among
the people working on documentation, including me.
Do you like getting paid? That is what I am proposing. I don't know
the likelyhood that the PF will buy into this, but it would seed
a lot of activity I think.
Yes I like getting paid, but I don't know why I've always been less
hesitating to contribute to unpaid projects. Perhaps because
accepting a
payment means real committing and a lot of responsability.
What I am going to write is little of topic, but I think it is
important
to the people who decides that kind of things.
I always like to incentive people to be motivated and I'm always studying
this subject. Right now I reading Drive (wrote by Daniel Pink).
I its very interesting what he points out on his book: there are some
studies (from Universities) that proves that business is doing the wrong
way. Business give money to motivate people and that way you can get the
opposite effect.
If someone is interested, fill free to contact me.
Thanks for everyone, Plone (including the community) is incredible :),
--
Felipe Roquette
www.krei.com.br
+55 11 3431.0303
Sorry... still off-topic but here goes...

I haven't read Pink but I suspect that you may be oversimplifying his
point. The science of motivation tells a more nuanced story. Whether
payments work or not depend largely on the type of work involved and
also on whether the payment is used as a contingent *reward* rather
than just as a way to obtain commitment. Depending on the type of
work, contingent rewards do appear to be counter-productive but that's
not what is being proposed here.

Another interesting author on this topic is Alfie Kohn.

Cheers,
Ric
Alex Clark
2010-04-15 13:56:10 UTC
Permalink
Post by Israel Saeta Pérez
Yes I like getting paid, but I don't know why I've always been less
hesitating to contribute to unpaid projects.
We all do it, it's human nature. What am I doing writing this email when I have
client work waiting? Etc. :-)
Post by Israel Saeta Pérez
Perhaps because accepting a
payment means real committing and a lot of responsability.
Correct. Sometimes that is appropriate. Sometimes it is not. Only you can
decide if you want to accept the responsibility and challenge.
Post by Israel Saeta Pérez
I'm already approving every document which is submitted for review to
the KB. I need to talk to Steve McMahon about the permission settings in
the KB.
The KB is fine but confusing, and subject to stalls induced by PHC and other
"dogbowl" issues. What I am proposing is to produce comprehensive, high
quality documentation in the form of manuals or whatever else makes
sense in combination with a software release.

In other words, here is Plone 4 and here is the associated "doc releases":

- End User Manual
- Knowledge Base
- Developer Guide
- Cheatsheet
- Leaflets
- Whatever

If something is in the way of doing this (e.g. PHC) move it out of the way
and focus on the release.
Post by Israel Saeta Pérez
If I didn't get it wrong, the work of the FWT is to vote PLIPs, not to
work on implementing them. The last is the task of the implementor.
Great point! Using that model, PLIPs come from anywhere and everywhere
and the Doc Team decides on what to include in a release.

So the model would be:

- Alex Clark submits doc PLIP #1, end user manual for Plone 4 and offers
to help write it.

- Doc team accepts/rejects.
Post by Israel Saeta Pérez
Well, I guess we could make the manuals release-wise and leave the KB
unversioned. Django has release-wise documentation and everybody likes
the Django docs. We can "experiment" with this approach.
We can do more than experiment ;-)
Post by Israel Saeta Pérez
1) If there's wrong info/errata in a manual, we would have to fix it in
all versions/releases, what is tedious. Are we talking about a manual
for each X.y version or just for X?
Work towards a release :-) The doc team leader perhaps in combination
with the FWT leader decides.
Post by Israel Saeta Pérez
2) We don't have the necessary PHC infrastructure and UI to present the
different versions of the manuals to the users. We could create a folder
for each version and copy-paste items to work on new releases, but I
don't know how to present this properly in the UI.
Work towards a release :-) If that is the case then I suggest we use
some tools that we don't have to maintain ourselves. We get
Plone 4 "for free" so perhaps eliminating PHC and using Just Plone 4™
would work. But again, the goal is to focus on the release…
Post by Israel Saeta Pérez
-- israel
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Israel Saeta Pérez
2010-04-19 07:43:51 UTC
Permalink
Hello there,
Post by Alex Clark
Post by Israel Saeta Pérez
I'm already approving every document which is submitted for review to
the KB. I need to talk to Steve McMahon about the permission settings in
the KB.
The KB is fine but confusing, and subject to stalls induced by PHC and other
"dogbowl" issues. What I am proposing is to produce comprehensive, high
quality documentation in the form of manuals or whatever else makes
sense in combination with a software release.
We just need a clean UI to make sure people understand that they can
edit and create docs in the KB freely. Limi is working on this.
Post by Alex Clark
- End User Manual
- Knowledge Base
- Developer Guide
- Cheatsheet
- Leaflets
- Whatever
If something is in the way of doing this (e.g. PHC) move it out of the way
and focus on the release.
I think there's some confusion in my mind about this point. I'm not sure
if with "doc release" you mean separate docs or just pointing to updated
ones. In the first case, as said earlier, maintaining all the previous
releases (to fix erratas or add info) can become cumbersome.

I think that, for now, we can just use the appropiate field to indicate
that certain documents apply to Plone 4 and create a collection from
them, or manually link them all (not so many) in a page if needed.
Post by Alex Clark
Post by Israel Saeta Pérez
If I didn't get it wrong, the work of the FWT is to vote PLIPs, not to
work on implementing them. The last is the task of the implementor.
Great point! Using that model, PLIPs come from anywhere and everywhere
and the Doc Team decides on what to include in a release.
- Alex Clark submits doc PLIP #1, end user manual for Plone 4 and offers
to help write it.
- Doc team accepts/rejects.
Only for new stuff, like existing PLIPs are for new features.

[...]
Post by Alex Clark
Post by Israel Saeta Pérez
1) If there's wrong info/errata in a manual, we would have to fix it in
all versions/releases, what is tedious. Are we talking about a manual
for each X.y version or just for X?
Work towards a release :-) The doc team leader perhaps in combination
with the FWT leader decides.
So far, we've been creating new versions of the Plone User Manual and
just updating the rest of the documentation, indicating "this feature is
new in Plone 4" where needed. We can decide for each release, yes. :)
Post by Alex Clark
Post by Israel Saeta Pérez
2) We don't have the necessary PHC infrastructure and UI to present the
different versions of the manuals to the users. We could create a folder
for each version and copy-paste items to work on new releases, but I
don't know how to present this properly in the UI.
Work towards a release :-) If that is the case then I suggest we use
some tools that we don't have to maintain ourselves. We get
Plone 4 "for free" so perhaps eliminating PHC and using Just Plone 4™
would work. But again, the goal is to focus on the release…
Plone 4 doesn't offer any UI for showing links to different versions of
the document either. I'm talking about something like LinguaPlone but
for software versions instead of languages. But we can do this manually
where needed for now.

If everybody believes that the figure of a "doc team leader" is
necessary, meaning the one who manages the efforts and levels the field
so everybody can contribute easily, but not the one who writes all the
documentation (which should be written by the developers themselves),
I'd be glad to serve.

Cheers,
-- israel
Alexander Limi
2010-04-19 08:07:31 UTC
Permalink
Post by Israel Saeta Pérez
We just need a clean UI to make sure people understand that they can
edit and create docs in the KB freely. Limi is working on this.
BTW, Weekend turned out busier than expected. Next attempt: Wednesday. Sorry
for the delay, it's at the top of my Plone list. :)
--
Alexander Limi · http://limi.net
Alex Clark
2010-04-21 01:02:02 UTC
Permalink
BTW, Weekend turned out busier than expected. Next attempt: Wednesday. Sorr=
y
for the delay, it's at the top of my Plone list. :)
GO! Maybe I'll have plone4.plone.org up by then ;-)
--=20
Alexander Limi =B7 http://limi.net
--000e0cd762261364fe048492757a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">2010/4/19 Israel Saeta P=E9rez <span dir=3D"ltr"=
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; =
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
We just need a clean UI to make sure people understand that they can<br>
edit and create docs in the KB freely. Limi is working on this.<br></blockq=
uote><div><br>BTW, Weekend turned out busier than expected. Next attempt: W=
ednesday. Sorry for the delay, it&#39;s at the top of my Plone list. :)<br =
clear=3D"all">
</div></div><br>-- <br>Alexander Limi =B7 <a href=3D"http://limi.net">http:=
//limi.net</a><br>
--000e0cd762261364fe048492757a--
--===============2281341327188544447==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--===============2281341327188544447==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
--===============2281341327188544447==--
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Alex Clark
2010-04-21 01:00:57 UTC
Permalink
Post by Israel Saeta Pérez
Hello there,
We just need a clean UI to make sure people understand that they can
edit and create docs in the KB freely. Limi is working on this.
Don't get me wrong, I think the KB is great. And if PHC is a good tool to use to
create a KB, even better. What I am trying to get people to move towards though
is a *release*.

Using the example you pointed me to the other day, you can look at 3 different
versions of the Django FAQ:

http://docs.djangoproject.com/en/dev/faq/
http://docs.djangoproject.com/en/1.0/faq/
http://docs.djangoproject.com/en/1.1/faq/

And here is another example, versioned installation docs from Zenoss:

http://community.zenoss.org/community/documentation/official_documentation/installation-guide

We should be doing the same with Plone's documentation, IMHO.
Post by Israel Saeta Pérez
I think there's some confusion in my mind about this point. I'm not sure
if with "doc release" you mean separate docs or just pointing to updated
ones.
I mean the documentation included in the release, which could come from
any number of sources. Just because it makes into a release, does not
mean it disappears from somewhere else e.g. the KB or Collective docs.
Post by Israel Saeta Pérez
In the first case, as said earlier, maintaining all the previous
releases (to fix erratas or add info) can become cumbersome.
If you view making a release as cumbersome, you are right: it is.
Developing and releasing Plone is cumbersome too :-p.
Post by Israel Saeta Pérez
I think that, for now, we can just use the appropiate field to indicate
that certain documents apply to Plone 4 and create a collection from
them, or manually link them all (not so many) in a page if needed.
Right, that is the status quo. If we start *releasing* documentation
for Plone though, I'd guess the soonest release we could do it with,
and most likely target is 4.1.
Post by Israel Saeta Pérez
Only for new stuff, like existing PLIPs are for new features.
No, not only for new stuff (documentation), but for a particular
release (of existing documentation). A PLIP is an improvement
proposal and take many forms e.g. adding, removing, restructuring.
It would probably be pretty easy to mimick the FWT PLIP process,
or join it.
Post by Israel Saeta Pérez
[...]
If everybody believes that the figure of a "doc team leader" is
necessary, meaning the one who manages the efforts and levels the field
so everybody can contribute easily, but not the one who writes all the
documentation (which should be written by the developers themselves),
I'd be glad to serve.
Great! I think that makes you the doc team leader (technically
release manager, in FWT-speak). Note: I have made this proposal to
the Foundation board and members and I expect a response, but I'm not
going to pursue it. I hope they decide in favor and that you and/or
future "documentation release managers" decide to pursue it.
But either way, it's been a productive conversation IMHO.
Post by Israel Saeta Pérez
Cheers,
-- israel
------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
John Schinnerer
2010-04-21 01:09:49 UTC
Permalink
Aloha,

Been following this thread silently...a comment from my docs-user
testing perspective:
It would be really (really, really) nice to know more clearly and
immediately and up-front which plone version(s) a doc is both relevant
to and correct for. I think this is part of the aim with a "release" of
docs, yes?

And, glad you are making clear that docs will not vanish from other
access routes just because they are part of a release. I assumed not,
and, good to see it in cyber-print.

thanks,
John S.
Post by Alex Clark
Post by Israel Saeta Pérez
Hello there,
We just need a clean UI to make sure people understand that they can
edit and create docs in the KB freely. Limi is working on this.
Don't get me wrong, I think the KB is great. And if PHC is a good tool to use to
create a KB, even better. What I am trying to get people to move towards though
is a *release*.
Using the example you pointed me to the other day, you can look at 3 different
http://docs.djangoproject.com/en/dev/faq/
http://docs.djangoproject.com/en/1.0/faq/
http://docs.djangoproject.com/en/1.1/faq/
http://community.zenoss.org/community/documentation/official_documentation/installation-guide
We should be doing the same with Plone's documentation, IMHO.
Post by Israel Saeta Pérez
I think there's some confusion in my mind about this point. I'm not sure
if with "doc release" you mean separate docs or just pointing to updated
ones.
I mean the documentation included in the release, which could come from
any number of sources. Just because it makes into a release, does not
mean it disappears from somewhere else e.g. the KB or Collective docs.
Post by Israel Saeta Pérez
In the first case, as said earlier, maintaining all the previous
releases (to fix erratas or add info) can become cumbersome.
If you view making a release as cumbersome, you are right: it is.
Developing and releasing Plone is cumbersome too :-p.
Post by Israel Saeta Pérez
I think that, for now, we can just use the appropiate field to indicate
that certain documents apply to Plone 4 and create a collection from
them, or manually link them all (not so many) in a page if needed.
Right, that is the status quo. If we start *releasing* documentation
for Plone though, I'd guess the soonest release we could do it with,
and most likely target is 4.1.
Post by Israel Saeta Pérez
Only for new stuff, like existing PLIPs are for new features.
No, not only for new stuff (documentation), but for a particular
release (of existing documentation). A PLIP is an improvement
proposal and take many forms e.g. adding, removing, restructuring.
It would probably be pretty easy to mimick the FWT PLIP process,
or join it.
Post by Israel Saeta Pérez
[...]
If everybody believes that the figure of a "doc team leader" is
necessary, meaning the one who manages the efforts and levels the field
so everybody can contribute easily, but not the one who writes all the
documentation (which should be written by the developers themselves),
I'd be glad to serve.
Great! I think that makes you the doc team leader (technically
release manager, in FWT-speak). Note: I have made this proposal to
the Foundation board and members and I expect a response, but I'm not
going to pursue it. I hope they decide in favor and that you and/or
future "documentation release managers" decide to pursue it.
But either way, it's been a productive conversation IMHO.
Post by Israel Saeta Pérez
Cheers,
-- israel
------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
--
John Schinnerer - M.A., Whole Systems Design
--------------------------------------------
- Eco-Living -
Whole Systems Design Services
People - Place - Learning - Integration
***@eco-living.net
http://eco-living.net
Dylan Jay
2010-04-21 02:02:28 UTC
Permalink
Post by Alex Clark
Post by Israel Saeta Pérez
Hello there,
We just need a clean UI to make sure people understand that they can
edit and create docs in the KB freely. Limi is working on this.
Don't get me wrong, I think the KB is great. And if PHC is a good tool to use to
create a KB, even better. What I am trying to get people to move towards though
is a *release*.
Using the example you pointed me to the other day, you can look at 3 different
http://docs.djangoproject.com/en/dev/faq/
http://docs.djangoproject.com/en/1.0/faq/
http://docs.djangoproject.com/en/1.1/faq/
I don't think it's nearly as unmanageable as has been suggested.

I think with using the collective.developermanual it's possible to
have many versions of the developer manual and even backport
documenation fixes to older branches. Each version will just be
overwritten with changes out of the appropriate svn branch nightly.

The plone user manual could be versioned for major versions if we
decide to not backport any enhancements to older versions. I think
thats fair enough since the manual is already very good and most new
changes will be reflecting new features anyway.

Dito for all the other manuals.

We just need a nicer folder structure.

Instead of

http://plone.org/documentation/manual/plone-3-user-manual

we could use

http://plone.org/documentation/manual/3.x/user-manual

and we could have a redirection to the latest e.g.

http://plone.org/documentation/manual/latest/user-manual

This would also mean we have 3 different versions of the manual page.
Instead of

http://plone.org/documentation/manual/

we would have

http://plone.org/documentation/manual/2.5
http://plone.org/documentation/manual/3.x
http://plone.org/documentation/manual/4.x


KB just works like the existing PHC docs, except that anyone can go in
and update the "versions" covered by a doc if a new plone version is
released and the documentation is still relevant to the new version.
Post by Alex Clark
http://community.zenoss.org/community/documentation/official_documentation/installation-guide
We should be doing the same with Plone's documentation, IMHO.
Post by Israel Saeta Pérez
I think there's some confusion in my mind about this point. I'm not sure
if with "doc release" you mean separate docs or just pointing to updated
ones.
I mean the documentation included in the release, which could come from
any number of sources. Just because it makes into a release, does not
mean it disappears from somewhere else e.g. the KB or Collective docs.
Post by Israel Saeta Pérez
In the first case, as said earlier, maintaining all the previous
releases (to fix erratas or add info) can become cumbersome.
If you view making a release as cumbersome, you are right: it is.
Developing and releasing Plone is cumbersome too :-p.
Post by Israel Saeta Pérez
I think that, for now, we can just use the appropiate field to indicate
that certain documents apply to Plone 4 and create a collection from
them, or manually link them all (not so many) in a page if needed.
Right, that is the status quo. If we start *releasing* documentation
for Plone though, I'd guess the soonest release we could do it with,
and most likely target is 4.1.
Post by Israel Saeta Pérez
Only for new stuff, like existing PLIPs are for new features.
No, not only for new stuff (documentation), but for a particular
release (of existing documentation). A PLIP is an improvement
proposal and take many forms e.g. adding, removing, restructuring.
It would probably be pretty easy to mimick the FWT PLIP process,
or join it.
Post by Israel Saeta Pérez
[...]
If everybody believes that the figure of a "doc team leader" is
necessary, meaning the one who manages the efforts and levels the field
so everybody can contribute easily, but not the one who writes all the
documentation (which should be written by the developers themselves),
I'd be glad to serve.
Great! I think that makes you the doc team leader (technically
release manager, in FWT-speak). Note: I have made this proposal to
the Foundation board and members and I expect a response, but I'm not
going to pursue it. I hope they decide in favor and that you and/or
future "documentation release managers" decide to pursue it.
But either way, it's been a productive conversation IMHO.
Post by Israel Saeta Pérez
Cheers,
-- israel
------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
------------------------------------------------------------------------------
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
Alex Clark
2010-05-09 17:55:25 UTC
Permalink
Hi, sorry meant to reply to this earlier…

On 2010-04-21, Dylan Jay <***@dylanjay.com> wrote:


Post by Dylan Jay
We just need a nicer folder structure.
Instead of
http://plone.org/documentation/manual/plone-3-user-manual
we could use
http://plone.org/documentation/manual/3.x/user-manual
and we could have a redirection to the latest e.g.
http://plone.org/documentation/manual/latest/user-manual
This would also mean we have 3 different versions of the manual page.
Instead of
http://plone.org/documentation/manual/
we would have
http://plone.org/documentation/manual/2.5
http://plone.org/documentation/manual/3.x
http://plone.org/documentation/manual/4.x
KB just works like the existing PHC docs, except that anyone can go in
and update the "versions" covered by a doc if a new plone version is
released and the documentation is still relevant to the new version.
+1000. Let's make it happen… I will probably have some time this month.

Of course, it'd be nice to get some other folks chiming in to agree
or disagree ;-)

--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Israel Saeta Pérez
2010-05-10 06:58:24 UTC
Permalink
Post by Alex Clark
Hi, sorry meant to reply to this earlier…

Post by Dylan Jay
We just need a nicer folder structure.
Instead of
http://plone.org/documentation/manual/plone-3-user-manual
we could use
http://plone.org/documentation/manual/3.x/user-manual
and we could have a redirection to the latest e.g.
http://plone.org/documentation/manual/latest/user-manual
This would also mean we have 3 different versions of the manual page.
Instead of
http://plone.org/documentation/manual/
we would have
http://plone.org/documentation/manual/2.5
http://plone.org/documentation/manual/3.x
http://plone.org/documentation/manual/4.x
KB just works like the existing PHC docs, except that anyone can go in
and update the "versions" covered by a doc if a new plone version is
released and the documentation is still relevant to the new version.
Yes, but remember that the KB is based PHC too.
Post by Alex Clark
+1000. Let's make it happen… I will probably have some time this month.
Of course, it'd be nice to get some other folks chiming in to agree
or disagree ;-)
Can't we use collections here? We already have the version metadata in
the manuals.

-- israel
Dylan Jay
2010-05-10 10:32:26 UTC
Permalink
Post by Israel Saeta Pérez
Post by Alex Clark
Hi, sorry meant to reply to this earlier…

Post by Dylan Jay
We just need a nicer folder structure.
Instead of
http://plone.org/documentation/manual/plone-3-user-manual
we could use
http://plone.org/documentation/manual/3.x/user-manual
and we could have a redirection to the latest e.g.
http://plone.org/documentation/manual/latest/user-manual
This would also mean we have 3 different versions of the manual page.
Instead of
http://plone.org/documentation/manual/
we would have
http://plone.org/documentation/manual/2.5
http://plone.org/documentation/manual/3.x
http://plone.org/documentation/manual/4.x
KB just works like the existing PHC docs, except that anyone can go in
and update the "versions" covered by a doc if a new plone version is
released and the documentation is still relevant to the new version.
Yes, but remember that the KB is based PHC too.
Post by Alex Clark
+1000. Let's make it happen… I will probably have some time this month.
Of course, it'd be nice to get some other folks chiming in to agree
or disagree ;-)
Can't we use collections here? We already have the version metadata in
the manuals.
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.
Israel Saeta Pérez
2010-05-13 11:27:42 UTC
Permalink
Post by Dylan Jay
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
Anne Bowtell
2010-05-13 11:53:13 UTC
Permalink
Post by Israel Saeta Pérez
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.
It's been a similar case for the theme reference, and as there are many
bits of the theme reference still to do (with potentially many people
still working on Plone 3) I'd be really uncomfortable about branching it
right now.
Post by Israel Saeta Pérez
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.
Yes, please, this is a nice discrete project that someone with design
skills could take on - any volunteers?
Post by Israel Saeta Pérez
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.
I agree. I've been talking to Israel about the possibility of defining
smaller tasks to undertake in the theme reference manual - if anyone
would like to lend a hand. With the current situation in my day job its
getting harder and harder for me to give up time for documentation work
and I'd really like to make it easy for someone else to pick up the work
on it.

Anne
Felipe Roquette
2010-05-13 12:38:53 UTC
Permalink
Hello!
Post by Israel Saeta Pérez
Post by Israel Saeta Pérez
IIRC Anne Botwell suggested time ago to create Kupu styles to
differentiate stuff targeted to specific versions of Plone in a
clear,
Post by Israel Saeta Pérez
consistent way along our documentation. Also, we can work to tag
docs
Post by Israel Saeta Pérez
with the correct version(s) they apply to, and try to improve the
way
Post by Israel Saeta Pérez
this info is presented to the user, so it's always clear to him/her.
Yes, please, this is a nice discrete project that someone with design
skills could take on - any volunteers?
I understood that it is something about design and Kupu styles but I
need more info to help.
Who can give some directions to start this task?


Greetings,
Felipe Roquette
***@krei.com.br

www.krei.com.br
+55 11 3431.0303


.
Alex Clark
2010-05-15 20:34:17 UTC
Permalink
Post by Israel Saeta Pérez
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.
Who cares? :-) That statement implies "avoiding duplicated content"
means "avoiding confusion" which I don't believe to be true.

For me, it comes down to this: I'm confused when I look at
http://plone.org/documentation (IOW approaching the project from an
outsider looking in) though I do occasionally find something useful via
Google.

So, if instead I went to http://plone.org/documentation and saw a link to something
like this:

http://www.turbogears.org/2.0/docs/

I would get a warm/fuzzy. Also, because I happen to be sitting in a TG2 class,
and I know the documentation for a newer TG2 release exists, I can go to:

http://www.turbogears.org/2.1/docs/

and experience a similar warm/fuzzy. I know this is not an Apples/Apples comparison,
I am just trying to point out that by "throwing your hands up" and invoking
"duplicate content" you have just prevented a large percentage of folks from
getting that warm/fuzzy. ;-)

There is (literally ;-)) no substitute for versioned docs, you either have
them or you don't.
Post by Israel Saeta Pérez
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.
That's not a bad idea, but I don't think it's any different than
"keywords" (i.e. tagging an object as compatible with a particular
version).
Post by Israel Saeta Pérez
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.
- Installation guide.
- Updated videos for the Plone 4 User Manual. The manual itself is
already published, with brand new screenshots. :)
If all of this makes folks happy, then of course don't listen to me. But
don't forget the other half of my proposal. If you feel a stipend might
help you to "help" (read: force) others to do a better job, by all means
nag the PF about it.
Post by Israel Saeta Pérez
Sorry for the long email!
No prob!
Post by Israel Saeta Pérez
-- israel
------------------------------------------------------------------------------
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
John Schinnerer
2010-05-15 22:44:40 UTC
Permalink
Aloha,

My two cents...
DRY is great for code.
Not so great for docs, IMO.
In current plone documentation, it can be really hard to tell what
version(s) a given piece of documentation applies to. And, even when
there is a label that says what it applies to, maybe it applies to newer
versions and just hasn't been maintained. Or maybe it doesn't and hasn't
been maintained. Or there's no indication. Or there is an indication and
the indication is just plain wrong. Or it's out of date but there's no
way to tell without doing what the doc says and finding out it doesn't
work....and so on.
I've had all these experiences at one time or another and if versioned
docs will reduce this significantly, I give it +100.

thanks,
John S.
Post by Alex Clark
Post by Israel Saeta Pérez
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.
Who cares? :-) That statement implies "avoiding duplicated content"
means "avoiding confusion" which I don't believe to be true.
For me, it comes down to this: I'm confused when I look at
http://plone.org/documentation (IOW approaching the project from an
outsider looking in) though I do occasionally find something useful via
Google.
So, if instead I went to http://plone.org/documentation and saw a link to something
http://www.turbogears.org/2.0/docs/
I would get a warm/fuzzy. Also, because I happen to be sitting in a TG2 class,
http://www.turbogears.org/2.1/docs/
and experience a similar warm/fuzzy. I know this is not an Apples/Apples comparison,
I am just trying to point out that by "throwing your hands up" and invoking
"duplicate content" you have just prevented a large percentage of folks from
getting that warm/fuzzy. ;-)
There is (literally ;-)) no substitute for versioned docs, you either have
them or you don't.
Post by Israel Saeta Pérez
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.
That's not a bad idea, but I don't think it's any different than
"keywords" (i.e. tagging an object as compatible with a particular
version).
Post by Israel Saeta Pérez
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.
- Installation guide.
- Updated videos for the Plone 4 User Manual. The manual itself is
already published, with brand new screenshots. :)
If all of this makes folks happy, then of course don't listen to me. But
don't forget the other half of my proposal. If you feel a stipend might
help you to "help" (read: force) others to do a better job, by all means
nag the PF about it.
Post by Israel Saeta Pérez
Sorry for the long email!
No prob!
Post by Israel Saeta Pérez
-- israel
------------------------------------------------------------------------------
--
John Schinnerer - M.A., Whole Systems Design
--------------------------------------------
- Eco-Living -
Whole Systems Design Services
People - Place - Learning - Integration
***@eco-living.net
http://eco-living.net
Alex Clark
2010-05-16 01:58:18 UTC
Permalink
Post by John Schinnerer
Aloha,
My two cents...
DRY is great for code.
Not so great for docs, IMO.
In current plone documentation, it can be really hard to tell what
version(s) a given piece of documentation applies to. And, even when
there is a label that says what it applies to, maybe it applies to newer
versions and just hasn't been maintained. Or maybe it doesn't and hasn't
been maintained. Or there's no indication. Or there is an indication and
the indication is just plain wrong. Or it's out of date but there's no
way to tell without doing what the doc says and finding out it doesn't
work....and so on.
Yes! Thank you for voicing my frustration :-)
Post by John Schinnerer
I've had all these experiences at one time or another and if versioned
docs will reduce this significantly, I give it +100.
Indeed, I believe they will, simply by making it abundantly clear and
unequivocally obvious what documentation you are reading (because
of the URL of the documentation, e.g. /documentation/4.0. How
much more clear can it get? ;-))
Post by John Schinnerer
thanks,
John S.
Post by Alex Clark
Post by Israel Saeta Pérez
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.
Who cares? :-) That statement implies "avoiding duplicated content"
means "avoiding confusion" which I don't believe to be true.
For me, it comes down to this: I'm confused when I look at
http://plone.org/documentation (IOW approaching the project from an
outsider looking in) though I do occasionally find something useful via
Google.
So, if instead I went to http://plone.org/documentation and saw a link to something
http://www.turbogears.org/2.0/docs/
I would get a warm/fuzzy. Also, because I happen to be sitting in a TG2 class,
http://www.turbogears.org/2.1/docs/
and experience a similar warm/fuzzy. I know this is not an Apples/Apples comparison,
I am just trying to point out that by "throwing your hands up" and invoking
"duplicate content" you have just prevented a large percentage of folks from
getting that warm/fuzzy. ;-)
There is (literally ;-)) no substitute for versioned docs, you either have
them or you don't.
Post by Israel Saeta Pérez
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.
That's not a bad idea, but I don't think it's any different than
"keywords" (i.e. tagging an object as compatible with a particular
version).
Post by Israel Saeta Pérez
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.
- Installation guide.
- Updated videos for the Plone 4 User Manual. The manual itself is
already published, with brand new screenshots. :)
If all of this makes folks happy, then of course don't listen to me. But
don't forget the other half of my proposal. If you feel a stipend might
help you to "help" (read: force) others to do a better job, by all means
nag the PF about it.
Post by Israel Saeta Pérez
Sorry for the long email!
No prob!
Post by Israel Saeta Pérez
-- israel
------------------------------------------------------------------------------
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
David Hostetler
2010-05-17 13:44:20 UTC
Permalink
Post by Alex Clark
unequivocally obvious what documentation you are reading (because
of the URL of the documentation, e.g. /documentation/4.0. How
much more clear can it get? ;-))
... or, rather, what documentation you *would* be reading, if it were
there. It does no good to have a bunch of tidy version-specific URLs
if there isn't comprehensive documentation to go under them.

Just being a little devil's advocate here, but isn't this notion of
formally versioning the docs putting the cart a bit before the horse?

Or are you of the opinion that versioning is worthwhile even if the
docs continue to be piecemeal and prone to decay?


The highwater mark, in my opinion, is the documentation of python
itself. I even keep local copies of the docs for 3 separate versions
(2.4*, 2.*, and 3.*). But imagine that python wasn't documenting
itself well and the documentation for, say, a third of its modules
only existed in 2.4. The value of any given version set is
proportional to its level of coverage.

Plopping people into a /documentation/4.0 folder is only compelling if
that's truly where they can get everything they need. If they're
constantly bumping into gaping holes and dead ends, and have to keep
jumping around between the version silos, then it's hardly a
warm-fuzzy inducing experience, and its even arguably *worse* than
what we've got now -- which is essentially a LIFO queue for doc
topics.


regards,

-David
Dylan Jay
2010-05-17 14:19:16 UTC
Permalink
Post by David Hostetler
Post by Alex Clark
unequivocally obvious what documentation you are reading (because
of the URL of the documentation, e.g. /documentation/4.0. How
much more clear can it get? ;-))
... or, rather, what documentation you *would* be reading, if it were
there. It does no good to have a bunch of tidy version-specific URLs
if there isn't comprehensive documentation to go under them.
Just being a little devil's advocate here, but isn't this notion of
formally versioning the docs putting the cart a bit before the horse?
Or are you of the opinion that versioning is worthwhile even if the
docs continue to be piecemeal and prone to decay?
probably you're referring to the developer documentation. The Plone
user manual I think is pretty comprehensive.

What we're really talking about versioning here is something like http://collective-docs.plone.org/
which still has holes but is far less piecemeal than the documentation
knowledge base (http://plone.org/documentation/kb).
Alex Clark
2010-05-17 22:09:43 UTC
Permalink
Hi all,
Post by Dylan Jay
What we're really talking about versioning here is something like http://collective-docs.plone.org/
which still has holes but is far less piecemeal than the documentation
knowledge base (http://plone.org/documentation/kb).
I think that we are all talking about different things, to some extent, but that this
has been, and continues to be a great thought/planning exercise.

Personally, after "going hard" at Plone for the past 5 years or so, I am starting
to take a look around and I see an awesome, but still "rough" project. My goal is to
"polish" the project from the top down, starting from within my area of expertise i.e.
systems and reaching out to other areas like the framework team and doc team as "needed" ;-)

So back to docs, I have no doubt the doc team can, and does produce awesome
documentation. I also have no doubts about what the Plone community can accomplish
if/when it sets its mind to something. Given that what I'm proposing for the doc team
to do is largely procedural, I coupled my suggestions with a pitch to the PF to fund some
of the work, in a way modeled after the über-successful framework team.

In fact, an easy way to think of what I am after is if you were suddenly
to make the "release manager" responsible for releasing documentation
in addition to software. What would that look like? It'd mean that in the
case of Plone 4.0, Eric Steele would suddenly have more work to do and would
probably investigate having me killed ;-)

But seriously. I picture that looking like a number of things
we've discussed i.e. versioning the documentation. But also, maybe
bundling documentation with the software a la Silva (if you
install the Silva CMS, you can add a "docs" folder to the
site, or something like that).

Dahoste is right in that "versioned docs" means nothing unless
there are docs to version. But it's not putting the cart before
the horse to talk about versioning. It's simply a procedural
step in which you declare "I am going to create a documentation 'release'".
What happens after that point, I referred to as "working towards a release".

To me, that work means these steps:

- Create an area of the site for "4.0 docs"

- Put manuals, faqs, whatever in there.
- installation manual
- end user manual
- developer manual
- pictures of limi in his lotus

- Work on the docs

- "Release" the docs (that means stop working on the docs ;-))

- Repeat for 4.x and 5.x et al

And that's basically it.

Thanks for listening, all!

Alex

P.S. I'm also a bit skeptical of the doc team's "But I don't to create duplicate content" position.
If the goal were to not duplicate content, then I'd agree my proposal would be "bad".
But isn't the goal to produce and maintain the highest quality documentation for Plone
releases? "We" (i.e. the doc team) are already doing that to a large degree. What I am
proposing is largely procedural. You could even make the arg it has nothing to do
with the doc team (i.e. it borders on the website team's domain, to some extent).
What are the *real* CONS to "duplicate" (but clearly separated) documentation, other
than offending personal preference?

It's like I said in a previous email, I don't view avoiding duplicate documentation
as any kind of "win", given the status quo.

But that could just be me. :-)
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Israel Saeta Pérez
2010-05-18 19:47:32 UTC
Permalink
Sorry for replying late, but I've been busy and all.
Post by Alex Clark
Dahoste is right in that "versioned docs" means nothing unless
there are docs to version. But it's not putting the cart before
the horse to talk about versioning. It's simply a procedural
step in which you declare "I am going to create a documentation 'release'".
What happens after that point, I referred to as "working towards a release".
- Create an area of the site for "4.0 docs"
- Put manuals, faqs, whatever in there.
- installation manual
- end user manual
- developer manual
- pictures of limi in his lotus
^^ Probably the most interesting part of the documentation. :P
Post by Alex Clark
- Work on the docs
- "Release" the docs (that means stop working on the docs ;-))
- Repeat for 4.x and 5.x et al
And that's basically it.
Thanks for listening, all!
Alex
P.S. I'm also a bit skeptical of the doc team's "But I don't to create duplicate content" position.
If the goal were to not duplicate content, then I'd agree my proposal would be "bad".
But isn't the goal to produce and maintain the highest quality documentation for Plone
releases? "We" (i.e. the doc team) are already doing that to a large degree. What I am
proposing is largely procedural. You could even make the arg it has nothing to do
with the doc team (i.e. it borders on the website team's domain, to some extent).
What are the *real* CONS to "duplicate" (but clearly separated) documentation, other
than offending personal preference?
It's like I said in a previous email, I don't view avoiding duplicate documentation
as any kind of "win", given the status quo.
In my opinion, your proposal is not just procedural but also structural.
Creating an area for 4.0 docs and putting docs there would mean that we
would have both the original doc and the one sitting in the 4.0 folder.
Whenever one wants to make an addition or correction valid for both
Plone 4 and 3, one would have to modify both documents.

Steve proposed to implement a traversal hack to display only docs tagged
for a certain version. For example, plone.org/documentation/4.x/
displaying only docs for Plone 4. I would be entirely ok with this
approach, since it doesn't duplicate content and therefore doesn't
create a maintenance problem. It would place the 4.x in the URL so you
would experience a great warm/fuzzy feeling. ;)

Regarding the stipend, I'm currently too busy with other jobs to be able
to allocate more time for this tasks, with or without money.
Post by Alex Clark
In current plone documentation, it can be really hard to tell what
version(s) a given piece of documentation applies to. And, even when
there is a label that says what it applies to, maybe it applies to newer
versions and just hasn't been maintained. Or maybe it doesn't and hasn't
been maintained. Or there's no indication. Or there is an indication and
the indication is just plain wrong. Or it's out of date but there's no
way to tell without doing what the doc says and finding out it doesn't
work....and so on.
We're working to keep manuals up-to-date and well tagged regarding the
version(s) they apply to. If you find any manual with incorrect/outdated
info, please open a ticket in the http://dev.plone.org/plone tracker,
documentation component, or mail me directly, and we will fix it.

-- israel
Alex Clark
2010-05-18 22:59:37 UTC
Permalink
Hi,
Post by Israel Saeta Pérez
Sorry for replying late, but I've been busy and all.
No problem.


Post by Israel Saeta Pérez
In my opinion, your proposal is not just procedural but also structural.
Creating an area for 4.0 docs and putting docs there would mean that we
would have both the original doc and the one sitting in the 4.0 folder.
Whenever one wants to make an addition or correction valid for both
Plone 4 and 3, one would have to modify both documents.
No, one would not have to do that. That is basically the point of a release.
After the 4.0 docs get "released" you don't touch them. You can keep working
on them, of course, somewhere else behind the scenes (We could use Plone! ;-))
and then when 4.1 comes out, you release your 4.1 docs.

And so on.

Also, the "site structure" of the website has absolutely nothing to do
with the Plone documentation IMO. The fact that the documentation team cares
*this* much about how the documentation is presented on plone.org kind of
surprises me. What if the FWT said "give us your documentation for the 4.0
release" and you *had* to submit something? That totally eliminates the website
from the equation.

Something to think about… ;-)
Post by Israel Saeta Pérez
Steve proposed to implement a traversal hack to display only docs tagged
for a certain version. For example, plone.org/documentation/4.x/
displaying only docs for Plone 4. I would be entirely ok with this
approach, since it doesn't duplicate content and therefore doesn't
create a maintenance problem. It would place the 4.x in the URL so you
would experience a great warm/fuzzy feeling. ;)
I would, but then I'd know where the bodies were buried so the fuzzy
would go away. But seriously, that might be a fair compromise… if someone
were willing to do the work (which I am not, I don't think).

Also, what is this "maintenance problem" you keep referring to? :-) Let me rephrase
that, can we agree, or at least be equally sensitive to the fact that not everyone is
of the opinion that copying content == "maintenance problem"? :-D
Post by Israel Saeta Pérez
Regarding the stipend, I'm currently too busy with other jobs to be able
to allocate more time for this tasks, with or without money.
Which is fine. And the PF may or may not give it to you if you asked. I
mention it mostly just to mention it.
Post by Israel Saeta Pérez
Post by John Schinnerer
In current plone documentation, it can be really hard to tell what
version(s) a given piece of documentation applies to. And, even when
there is a label that says what it applies to, maybe it applies to newer
versions and just hasn't been maintained. Or maybe it doesn't and hasn't
been maintained. Or there's no indication. Or there is an indication and
the indication is just plain wrong. Or it's out of date but there's no
way to tell without doing what the doc says and finding out it doesn't
work....and so on.
We're working to keep manuals up-to-date and well tagged regarding the
version(s) they apply to. If you find any manual with incorrect/outdated
info, please open a ticket in the http://dev.plone.org/plone tracker,
documentation component, or mail me directly, and we will fix it.
But you wouldn't know, unless you knew. "Open a ticket if you find a
mistake" only applies to a very small subset of folks (i.e. us). Everyone
else going to /documentation expects to see… current documentation.
Post by Israel Saeta Pérez
-- israel
------------------------------------------------------------------------------
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
John Schinnerer
2010-05-18 23:29:05 UTC
Permalink
Aloha,
Post by Alex Clark
Post by Israel Saeta Pérez
We're working to keep manuals up-to-date and well tagged regarding the
version(s) they apply to. If you find any manual with incorrect/outdated
info, please open a ticket in the http://dev.plone.org/plone tracker,
documentation component, or mail me directly, and we will fix it.
But you wouldn't know, unless you knew. "Open a ticket if you find a
mistake" only applies to a very small subset of folks (i.e. us). Everyone
else going to /documentation expects to see… current documentation.
Ditto, more or less...I'd file a ticket probably, and/or create a KB
item if that seemed more immediately useful.
People starting out with the platform, or more in end-user roles (e.g.
site admin, etc.), may have a lower level of frustration and/or
commitment. They may fuss and complain (or just give up) but not file a
ticket (or even think to do such a thing).

I've had more struggles with absent information than mistaken
information. If I can find what I need and it is applicable to my
version/context, it's usually correct. It's what I can't find (or do
find but cannot tell if it's applicable without trial and error
overhead) that I'm more concerned about.

thanks,
John S.
Post by Alex Clark
Post by Israel Saeta Pérez
-- israel
------------------------------------------------------------------------------
--
John Schinnerer - M.A., Whole Systems Design
--------------------------------------------
- Eco-Living -
Whole Systems Design Services
People - Place - Learning - Integration
***@eco-living.net
http://eco-living.net
Anne Bowtell
2010-05-19 08:39:37 UTC
Permalink
Post by Alex Clark
Post by Israel Saeta Pérez
In my opinion, your proposal is not just procedural but also structural.
Creating an area for 4.0 docs and putting docs there would mean that we
would have both the original doc and the one sitting in the 4.0 folder.
Whenever one wants to make an addition or correction valid for both
Plone 4 and 3, one would have to modify both documents.
No, one would not have to do that. That is basically the point of a release.
After the 4.0 docs get "released" you don't touch them. You can keep working
on them, of course, somewhere else behind the scenes (We could use Plone! ;-))
and then when 4.1 comes out, you release your 4.1 docs.
OK, that's fine going forward, but what about the Plone 3 documentation.
With respect to the theme reference manual - it does not yet document
everything that's required for Plone 3 theming. So is that just
abandoned, half-finished? There are plenty of people around still using
Plone 3.
Post by Alex Clark
Also, the "site structure" of the website has absolutely nothing to do
with the Plone documentation IMO. The fact that the documentation team cares
*this* much about how the documentation is presented on plone.org kind of
surprises me.
Well, it's because we're aware of what needs to be done, the size of the
task ahead of us, how thin on the ground and, to a certain extent,
de-moralized the documentation 'team' is, how unfinished the current
projects are, and how much we're relying on one person (Israel) to hold
it all together at the moment. Just making big plans when what we need
to do is get our heads down and work out how to get the Plone 4
documentation required done (and all the boring, mundane tasks like
screenshots that that required) is taking a great deal of energy. This
isn't really the time for big plans.

And, I can tell you, that trying to organize and structure the manual
that I put together was tough but also really important. I'm sort of
surprised that you should think that we wouldn't be concerned about
presentation and structure.
Post by Alex Clark
I would, but then I'd know where the bodies were buried so the fuzzy
would go away. But seriously, that might be a fair compromise
 if someone
were willing to do the work (which I am not, I don't think).
Also, what is this "maintenance problem" you keep referring to? :-) Let me rephrase
that, can we agree, or at least be equally sensitive to the fact that not everyone is
of the opinion that copying content == "maintenance problem"? :-D
But the people who have to do the work of maintaining the documentation,
*are* of that opinion. You mention in the previous paragraph, that
you're not willing to engage in a task or commit to a course of action
that you feel isn't appropriate - which is fair enough. But that's what
you're asking us to do.

I'm demoralized enough as it is, but I have to say that yesterday I
spent the whole morning helping a colleague who wanted to build his
first content type and I simply couldn't find the information he needed
on plone.org (although I'm sure its buried there somewhere) - so I've
been writing it all up on my own website. It made no difference whether
this was Plone 4 or 4.1 - in actual fact it was Plone 3 - whatever he
did would have been pretty much relevant to both. The information he
needed just wasn't discoverable and not delivered in a format that
helped him, as an integrator, complete the task that he had to do.
That's the bigger picture and the bigger problem.

We all want a more polished Plone, but the reality is that there
fundamental things to do in building a community of documentors who
actually write documentation for end users, integrators and developers.
Who maybe have experience in these all these roles or have experience in
helping people in these roles. There's room for blue-skies thinking of
course, but I just don't think that right now this discussion is helping
us much.

If everyone who's been involved in the discussion could commit to
completing at least two documentation tickets over the weekend and
encouraging someone new to join into the documentation process by
dealing with a ticket, then perhaps we'd be in a position to move forward.

Thanks

Anne
Dylan Jay
2010-05-19 09:02:32 UTC
Permalink
I can really hear the pain here and see the demoralisation. There is
so much work to do and not enough people to do it.

but let me just put this out there. If no one else new is
contributing, what is the reason why?

Perhaps the current process isn't working for them and so they are
turned off.

The #1 problem with plone is developer documentation rather than user
manual documentation. We have Mikko which has put a huge amount of
effort into a new developer manual which I think is now more useful
than the current developer manual. He did it in sphinx because it has
a documentation process more familiar to developers. Lots of others
have expressed their desire to document Plone this way. Yet there has
been continued resistance to making the collective developer manual
official. So we're stuck with a documentation process that isn't
attracting anyone new and telling a whole bunch of developers they
can't document unless they do that using that old way.

I know I sound like a broken record on this subject. It's not because
I'm trying to be a smart arse, or trying to be right or anything. It's
because I honestly honestly believe this will work. We'll get more
developers documenting Plone in a more controlled fashion. It will be
easy to version and therefore make more readers trust it. The more
developers actually start relying on a single developer manual the
more they will want to contribute. It's a virtuous circle. Give it a
try. Pleeeeeeeeeaaaaaasssssssseeeeeeeee :)
Post by Anne Bowtell
Post by Alex Clark
Post by Israel Saeta Pérez
In my opinion, your proposal is not just procedural but also
structural.
Creating an area for 4.0 docs and putting docs there would mean that we
would have both the original doc and the one sitting in the 4.0 folder.
Whenever one wants to make an addition or correction valid for both
Plone 4 and 3, one would have to modify both documents.
No, one would not have to do that. That is basically the point of a release.
After the 4.0 docs get "released" you don't touch them. You can keep working
on them, of course, somewhere else behind the scenes (We could use Plone! ;-))
and then when 4.1 comes out, you release your 4.1 docs.
OK, that's fine going forward, but what about the Plone 3
documentation. With respect to the theme reference manual - it does
not yet document everything that's required for Plone 3 theming. So
is that just abandoned, half-finished? There are plenty of people
around still using Plone 3.
Post by Alex Clark
Also, the "site structure" of the website has absolutely nothing to do
with the Plone documentation IMO. The fact that the documentation team cares
*this* much about how the documentation is presented on plone.org kind of
surprises me.
Well, it's because we're aware of what needs to be done, the size of
the task ahead of us, how thin on the ground and, to a certain
extent, de-moralized the documentation 'team' is, how unfinished the
current projects are, and how much we're relying on one person
(Israel) to hold it all together at the moment. Just making big
plans when what we need to do is get our heads down and work out how
to get the Plone 4 documentation required done (and all the boring,
mundane tasks like screenshots that that required) is taking a great
deal of energy. This isn't really the time for big plans.
And, I can tell you, that trying to organize and structure the
manual that I put together was tough but also really important. I'm
sort of surprised that you should think that we wouldn't be
concerned about presentation and structure.
Post by Alex Clark
I would, but then I'd know where the bodies were buried so the fuzzy
would go away. But seriously, that might be a fair compromise… if
someone
were willing to do the work (which I am not, I don't think).
Also, what is this "maintenance problem" you keep referring to? :-) Let me rephrase
that, can we agree, or at least be equally sensitive to the fact that not everyone is
of the opinion that copying content == "maintenance problem"? :-D
But the people who have to do the work of maintaining the
documentation, *are* of that opinion. You mention in the previous
paragraph, that you're not willing to engage in a task or commit to
a course of action that you feel isn't appropriate - which is fair
enough. But that's what you're asking us to do.
I'm demoralized enough as it is, but I have to say that yesterday I
spent the whole morning helping a colleague who wanted to build his
first content type and I simply couldn't find the information he
needed on plone.org (although I'm sure its buried there somewhere) -
so I've been writing it all up on my own website. It made no
difference whether this was Plone 4 or 4.1 - in actual fact it was
Plone 3 - whatever he did would have been pretty much relevant to
both. The information he needed just wasn't discoverable and not
delivered in a format that helped him, as an integrator, complete
the task that he had to do. That's the bigger picture and the bigger
problem.
We all want a more polished Plone, but the reality is that there
fundamental things to do in building a community of documentors who
actually write documentation for end users, integrators and
developers. Who maybe have experience in these all these roles or
have experience in helping people in these roles. There's room for
blue-skies thinking of course, but I just don't think that right now
this discussion is helping us much.
If everyone who's been involved in the discussion could commit to
completing at least two documentation tickets over the weekend and
encouraging someone new to join into the documentation process by
dealing with a ticket, then perhaps we'd be in a position to move forward.
Thanks
Anne
<
anne_bowtell
.vcf
------------------------------------------------------------------------------
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
Israel Saeta Pérez
2010-05-19 14:24:12 UTC
Permalink
Post by Dylan Jay
The #1 problem with plone is developer documentation rather than user
manual documentation. We have Mikko which has put a huge amount of
effort into a new developer manual which I think is now more useful
than the current developer manual. He did it in sphinx because it has
a documentation process more familiar to developers. Lots of others
have expressed their desire to document Plone this way. Yet there has
been continued resistance to making the collective developer manual
official. So we're stuck with a documentation process that isn't
attracting anyone new and telling a whole bunch of developers they
can't document unless they do that using that old way.
That's quite untrue. Mikko has been granted access to publish the manual
pulled from the sphinx docs at plone.org whenever they're ready to do so
(e.g. no spurious "_static", "index", etc. pages and all).

-- israel


-----
Israel Saeta Pérez
--
View this message in context: http://plone.293351.n2.nabble.com/Proposal-to-manage-documentation-similar-to-or-along-with-core-software-tp4899546p5075101.html
Sent from the Documentation Team mailing list archive at Nabble.com.
Dylan Jay
2010-05-19 21:29:45 UTC
Permalink
Post by Israel Saeta Pérez
Post by Dylan Jay
The #1 problem with plone is developer documentation rather than user
manual documentation. We have Mikko which has put a huge amount of
effort into a new developer manual which I think is now more useful
than the current developer manual. He did it in sphinx because it has
a documentation process more familiar to developers. Lots of others
have expressed their desire to document Plone this way. Yet there has
been continued resistance to making the collective developer manual
official. So we're stuck with a documentation process that isn't
attracting anyone new and telling a whole bunch of developers they
can't document unless they do that using that old way.
That's quite untrue. Mikko has been granted access to publish the manual
pulled from the sphinx docs at plone.org whenever they're ready to do so
(e.g. no spurious "_static", "index", etc. pages and all).
That's fantastic news I wasn't aware of
Post by Israel Saeta Pérez
-- israel
-----
Israel Saeta Pérez
--
View this message in context: http://plone.293351.n2.nabble.com/Proposal-to-manage-documentation-similar-to-or-along-with-core-software-tp4899546p5075101.html
Sent from the Documentation Team mailing list archive at Nabble.com.
---
---
---
---------------------------------------------------------------------
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
Alex Clark
2010-05-19 23:55:55 UTC
Permalink
Post by Dylan Jay
The #1 problem with plone is developer documentation rather than user
manual documentation. We have Mikko which has put a huge amount of
effort into a new developer manual which I think is now more useful
than the current developer manual. He did it in sphinx because it has
a documentation process more familiar to developers. Lots of others
have expressed their desire to document Plone this way. Yet there has
been continued resistance to making the collective developer manual
official. So we're stuck with a documentation process that isn't
attracting anyone new and telling a whole bunch of developers they
can't document unless they do that using that old way.
+1. There should be *zero* pushback from the documentation team on
Sphinx generated documentation IMO. Let's just find a way to
assemble our collective efforts in a sane way, whatever they/that may be.

/documentation kicks ass, it just needs help,
collective-docs kicks ass, it just needs acceptance :-)
Post by Dylan Jay
I know I sound like a broken record on this subject. It's not because
I'm trying to be a smart arse, or trying to be right or anything. It's
because I honestly honestly believe this will work. We'll get more
developers documenting Plone in a more controlled fashion. It will be
easy to version and therefore make more readers trust it. The more
developers actually start relying on a single developer manual the
more they will want to contribute. It's a virtuous circle. Give it a
try. Pleeeeeeeeeaaaaaasssssssseeeeeeeee :)
Indeed, let me ask you this. Would you be happy if a 3.3.6 and 4.0
PHC existed on plone.org to house collective-docs (in the way
you guys setup)?

This would achieve versioning, more or less.

I imagine you would manage branches, tags and trunks yourselves
in the collective, and then when 4.0 (e.g.) got released on
plone.org you would *stop* updating that PHC ;-)

In this way, I believe you are right, people would go to

http://plone.org/documentation/4.0/developer-manual
(or http://plone.org/documentation/4.0/collective-developer-manual ? do we have two of them?)

and see that their contributions to the collective ending up on plone.org and
get excited ;-)

That may be a gateway to joining the "real" docs team (for lack of a better
way to put it, and no offense intended, of course :-)).

Alex
Post by Dylan Jay
Post by Anne Bowtell
Post by Alex Clark
Post by Israel Saeta Pérez
In my opinion, your proposal is not just procedural but also structural.
Creating an area for 4.0 docs and putting docs there would mean that we
would have both the original doc and the one sitting in the 4.0 folder.
Whenever one wants to make an addition or correction valid for both
Plone 4 and 3, one would have to modify both documents.
No, one would not have to do that. That is basically the point of a release.
After the 4.0 docs get "released" you don't touch them. You can keep working
on them, of course, somewhere else behind the scenes (We could use Plone! ;-))
and then when 4.1 comes out, you release your 4.1 docs.
OK, that's fine going forward, but what about the Plone 3
documentation. With respect to the theme reference manual - it does
not yet document everything that's required for Plone 3 theming. So
is that just abandoned, half-finished? There are plenty of people
around still using Plone 3.
Post by Alex Clark
Also, the "site structure" of the website has absolutely nothing to do
with the Plone documentation IMO. The fact that the documentation team cares
*this* much about how the documentation is presented on plone.org kind of
surprises me.
Well, it's because we're aware of what needs to be done, the size of
the task ahead of us, how thin on the ground and, to a certain
extent, de-moralized the documentation 'team' is, how unfinished the
current projects are, and how much we're relying on one person
(Israel) to hold it all together at the moment. Just making big
plans when what we need to do is get our heads down and work out how
to get the Plone 4 documentation required done (and all the boring,
mundane tasks like screenshots that that required) is taking a great
deal of energy. This isn't really the time for big plans.
And, I can tell you, that trying to organize and structure the
manual that I put together was tough but also really important. I'm
sort of surprised that you should think that we wouldn't be
concerned about presentation and structure.
Post by Alex Clark
I would, but then I'd know where the bodies were buried so the fuzzy
would go away. But seriously, that might be a fair compromise… if
someone
were willing to do the work (which I am not, I don't think).
Also, what is this "maintenance problem" you keep referring to? :-) Let me rephrase
that, can we agree, or at least be equally sensitive to the fact that not everyone is
of the opinion that copying content == "maintenance problem"? :-D
But the people who have to do the work of maintaining the
documentation, *are* of that opinion. You mention in the previous
paragraph, that you're not willing to engage in a task or commit to
a course of action that you feel isn't appropriate - which is fair
enough. But that's what you're asking us to do.
I'm demoralized enough as it is, but I have to say that yesterday I
spent the whole morning helping a colleague who wanted to build his
first content type and I simply couldn't find the information he
needed on plone.org (although I'm sure its buried there somewhere) -
so I've been writing it all up on my own website. It made no
difference whether this was Plone 4 or 4.1 - in actual fact it was
Plone 3 - whatever he did would have been pretty much relevant to
both. The information he needed just wasn't discoverable and not
delivered in a format that helped him, as an integrator, complete
the task that he had to do. That's the bigger picture and the bigger
problem.
We all want a more polished Plone, but the reality is that there
fundamental things to do in building a community of documentors who
actually write documentation for end users, integrators and
developers. Who maybe have experience in these all these roles or
have experience in helping people in these roles. There's room for
blue-skies thinking of course, but I just don't think that right now
this discussion is helping us much.
If everyone who's been involved in the discussion could commit to
completing at least two documentation tickets over the weekend and
encouraging someone new to join into the documentation process by
dealing with a ticket, then perhaps we'd be in a position to move forward.
Thanks
Anne
<
anne_bowtell
.vcf
------------------------------------------------------------------------------
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
------------------------------------------------------------------------------
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Alex Clark
2010-05-19 23:45:07 UTC
Permalink
Hi Anne!
Post by Anne Bowtell
OK, that's fine going forward, but what about the Plone 3 documentation.
Let it die. Unless there is a 3.3.6, in which case I'd release whatever documentation
has changed since you released the 3.3.5 documentation. Note:

- Of course, there are no "3.3.5 docs" right now. But you could take the existing
set of "Plone 3 docs" and release them as the "3.3.5. docs" If there are things
in that set of docs that don't apply to 3.2 or 3.1 or 3.0, then so be it. I'm
not sure I'd worry about that at this point.

- If you were to do that, then you'd continue edit the 3.3.5 docs in private until
such time as 3.3.6 comes out (if it comes out).
Post by Anne Bowtell
With respect to the theme reference manual - it does not yet document
everything that's required for Plone 3 theming. So is that just
abandoned, half-finished? There are plenty of people around still using
Plone 3.
See above, the short answer is "don't worry about it." (IMO)
Post by Anne Bowtell
Well, it's because we're aware of what needs to be done, the size of the
task ahead of us, how thin on the ground and, to a certain extent,
de-moralized the documentation 'team' is, how unfinished the current
projects are, and how much we're relying on one person (Israel) to hold
it all together at the moment. Just making big plans when what we need
to do is get our heads down and work out how to get the Plone 4
documentation required done (and all the boring, mundane tasks like
screenshots that that required) is taking a great deal of energy. This
isn't really the time for big plans.
Any time is the time for big plans IMO, but I hear you. To be honest,
I'm not so sure it would be *that* bad to release the current set of
documentation as the 3.3.5 documentation, and keep developing the 4.0
documentation "in private" until such time as it is ready. This is
open source, so people will get it when they get it. (IMO)

Remember, no one really knows what you guys are doing (IMVHO). I'm trying to
bridge the gap between the hard work that is occuring, and the
perception of the general public which is "confusing docs".
Post by Anne Bowtell
And, I can tell you, that trying to organize and structure the manual
that I put together was tough but also really important. I'm sort of
surprised that you should think that we wouldn't be concerned about
presentation and structure.
No, I understand you are concerned about that, *within* your documentation.
What I don't understand is why you care *where* your documentation
is placed on the website, e.g.:

/documentation/

vs.

/documentation/3.3.5
/documentation/4.0

And so on.
Post by Anne Bowtell
But the people who have to do the work of maintaining the documentation,
*are* of that opinion. You mention in the previous paragraph, that
you're not willing to engage in a task or commit to a course of action
that you feel isn't appropriate - which is fair enough. But that's what
you're asking us to do.
Not quite. I'm asking that folks consider my proposal to "version"
documentation. Period. And a postcript: I'm also asking that they be
continually be aware (in the background, so to speak) that I formally
asked the PF for money to fund the documentation effort, in case it's
ever needed, or desired in the future.

That said, in terms of *actual* work you have to do, everything
I am proposing could probably be done outside the scope
of the documentation team's efforts, whatever they are. Perhaps
that is where the confusion is occuring.

There are at least two other teams peripherally involved:

- FWT
- Website team

But also:

- Evangelism
- Marketing

(Are these different?)

In short, *everyone* that does Plone is at least "loosely" concerned
about the public-facing documentation.

Of all these folks, which is everyone basically :-), it is probably safe
to say that *none* of them would want to discourage the documentation
team in any way from doing what it is doing. That is not at all what
this is about. In fact, just the opposite. I think everyone appreciates
that we have such dedicated folks.

What this is about is "framing" and "clarifying" and "tranparency-i-fying"
our documentation team's efforts. I could login to plone.org right now
and rename /documentation to /3.3.5, and create a /documentation folder
(not help center) and move /3.3.5 to it to create /documentation/3.3.5.

Once 3.3.5 is created, we could further split it into:

/documentation/release/3.3.5
/documentation/develop/3.3.6
/documentation/develop/4.0

So, at this point, 3.3.5 would not get touched. 3.3.6 would get fixes
to 3.3.5 and 4.0 would receive the full 4.0 treatment.

When 4.1 approaches, you repeat the process.

I am willing to do a great many things to assist in making this
happen. I only mentioned not being willing to work on a traversal
hack because I don't fully understand how that would work. I
suspect it won't work the way I want it to ;-)
Post by Anne Bowtell
I'm demoralized enough as it is, but I have to say that yesterday I
spent the whole morning helping a colleague who wanted to build his
first content type and I simply couldn't find the information he needed
on plone.org (although I'm sure its buried there somewhere) - so I've
been writing it all up on my own website. It made no difference whether
this was Plone 4 or 4.1 - in actual fact it was Plone 3 - whatever he
did would have been pretty much relevant to both. The information he
needed just wasn't discoverable and not delivered in a format that
helped him, as an integrator, complete the task that he had to do.
That's the bigger picture and the bigger problem.
Yeah, I got questions in my class like "is all this stuff going to
be anywhere but in PP3 or your PSA book?" and I had to give them my generic
answer: there is great stuff on plone.org if you know where to find
it (e.g. a search for apache gives you
http://plone.org/documentation/kb/plone-with-apache/)
Post by Anne Bowtell
We all want a more polished Plone, but the reality is that there
fundamental things to do in building a community of documentors who
actually write documentation for end users, integrators and developers.
Who maybe have experience in these all these roles or have experience in
helping people in these roles. There's room for blue-skies thinking of
course, but I just don't think that right now this discussion is helping
us much.
Hmmm, well that is a fair point. But I am just trying to prevent "stop energy".
When I hear things like "I don't want to duplicate content" my stop energy
bell goes off ;-)
Post by Anne Bowtell
If everyone who's been involved in the discussion could commit to
completing at least two documentation tickets over the weekend and
encouraging someone new to join into the documentation process by
dealing with a ticket, then perhaps we'd be in a position to move forward.
Heh. If you guys let me rename the PHCs and such on plone.org, I'll start writing
docs (and fixing tickets :-).

Seriously, my book is wrapping up soon, and I very much hope to have more time to
devote to documentation "proper".
Post by Anne Bowtell
Thanks
Anne
--------------030400080905070405060401
Content-Type: text/x-vcard; charset=utf-8;
name="anne_bowtell.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="anne_bowtell.vcf"
YmVnaW46dmNhcmQNCmZuOkFubmUgQm93dGVsbA0KbjpCb3d0ZWxsO0FubmUNCmVtYWlsO2lu
dGVybmV0OmFubmUuYm93dGVsbEBtZWRzY2kub3guYWMudWsNCnRlbDt3b3JrOis0NCAoMCkx
ODY1IDg4MjgyOQ0KeC1tb3ppbGxhLWh0bWw6RkFMU0UNCnZlcnNpb246Mi4xDQplbmQ6dmNh
cmQNCg0K
--------------030400080905070405060401
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
------------------------------------------------------------------------------
--------------030400080905070405060401
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
--------------030400080905070405060401--
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Dylan Jay
2010-05-20 01:53:39 UTC
Permalink
I actually think versioning by major version is enough

e.g. documentation/manuals/plone4/developer
documentation/manuals/plone3/developer
Post by Alex Clark
Hi Anne!
Post by Anne Bowtell
OK, that's fine going forward, but what about the Plone 3
documentation.
Let it die. Unless there is a 3.3.6, in which case I'd release
whatever documentation
- Of course, there are no "3.3.5 docs" right now. But you could take the existing
set of "Plone 3 docs" and release them as the "3.3.5. docs" If there are things
in that set of docs that don't apply to 3.2 or 3.1 or 3.0, then so be it. I'm
not sure I'd worry about that at this point.
- If you were to do that, then you'd continue edit the 3.3.5 docs in private until
such time as 3.3.6 comes out (if it comes out).
Post by Anne Bowtell
With respect to the theme reference manual - it does not yet document
everything that's required for Plone 3 theming. So is that just
abandoned, half-finished? There are plenty of people around still using
Plone 3.
See above, the short answer is "don't worry about it." (IMO)
Post by Anne Bowtell
Well, it's because we're aware of what needs to be done, the size of the
task ahead of us, how thin on the ground and, to a certain extent,
de-moralized the documentation 'team' is, how unfinished the current
projects are, and how much we're relying on one person (Israel) to hold
it all together at the moment. Just making big plans when what we need
to do is get our heads down and work out how to get the Plone 4
documentation required done (and all the boring, mundane tasks like
screenshots that that required) is taking a great deal of energy. This
isn't really the time for big plans.
Any time is the time for big plans IMO, but I hear you. To be honest,
I'm not so sure it would be *that* bad to release the current set of
documentation as the 3.3.5 documentation, and keep developing the 4.0
documentation "in private" until such time as it is ready. This is
open source, so people will get it when they get it. (IMO)
Remember, no one really knows what you guys are doing (IMVHO). I'm trying to
bridge the gap between the hard work that is occuring, and the
perception of the general public which is "confusing docs".
Post by Anne Bowtell
And, I can tell you, that trying to organize and structure the manual
that I put together was tough but also really important. I'm sort of
surprised that you should think that we wouldn't be concerned about
presentation and structure.
No, I understand you are concerned about that, *within* your
documentation.
What I don't understand is why you care *where* your documentation
/documentation/
vs.
/documentation/3.3.5
/documentation/4.0
And so on.
Post by Anne Bowtell
But the people who have to do the work of maintaining the
documentation,
*are* of that opinion. You mention in the previous paragraph, that
you're not willing to engage in a task or commit to a course of action
that you feel isn't appropriate - which is fair enough. But that's what
you're asking us to do.
Not quite. I'm asking that folks consider my proposal to "version"
documentation. Period. And a postcript: I'm also asking that they be
continually be aware (in the background, so to speak) that I formally
asked the PF for money to fund the documentation effort, in case it's
ever needed, or desired in the future.
That said, in terms of *actual* work you have to do, everything
I am proposing could probably be done outside the scope
of the documentation team's efforts, whatever they are. Perhaps
that is where the confusion is occuring.
- FWT
- Website team
- Evangelism
- Marketing
(Are these different?)
In short, *everyone* that does Plone is at least "loosely" concerned
about the public-facing documentation.
Of all these folks, which is everyone basically :-), it is probably safe
to say that *none* of them would want to discourage the documentation
team in any way from doing what it is doing. That is not at all what
this is about. In fact, just the opposite. I think everyone
appreciates
that we have such dedicated folks.
What this is about is "framing" and "clarifying" and "tranparency-i-
fying"
our documentation team's efforts. I could login to plone.org right now
and rename /documentation to /3.3.5, and create a /documentation folder
(not help center) and move /3.3.5 to it to create /documentation/
3.3.5.
/documentation/release/3.3.5
/documentation/develop/3.3.6
/documentation/develop/4.0
So, at this point, 3.3.5 would not get touched. 3.3.6 would get fixes
to 3.3.5 and 4.0 would receive the full 4.0 treatment.
When 4.1 approaches, you repeat the process.
I am willing to do a great many things to assist in making this
happen. I only mentioned not being willing to work on a traversal
hack because I don't fully understand how that would work. I
suspect it won't work the way I want it to ;-)
Post by Anne Bowtell
I'm demoralized enough as it is, but I have to say that yesterday I
spent the whole morning helping a colleague who wanted to build his
first content type and I simply couldn't find the information he needed
on plone.org (although I'm sure its buried there somewhere) - so I've
been writing it all up on my own website. It made no difference whether
this was Plone 4 or 4.1 - in actual fact it was Plone 3 - whatever he
did would have been pretty much relevant to both. The information he
needed just wasn't discoverable and not delivered in a format that
helped him, as an integrator, complete the task that he had to do.
That's the bigger picture and the bigger problem.
Yeah, I got questions in my class like "is all this stuff going to
be anywhere but in PP3 or your PSA book?" and I had to give them my generic
answer: there is great stuff on plone.org if you know where to find
it (e.g. a search for apache gives you
http://plone.org/documentation/kb/plone-with-apache/)
Post by Anne Bowtell
We all want a more polished Plone, but the reality is that there
fundamental things to do in building a community of documentors who
actually write documentation for end users, integrators and
developers.
Who maybe have experience in these all these roles or have
experience in
helping people in these roles. There's room for blue-skies thinking of
course, but I just don't think that right now this discussion is helping
us much.
Hmmm, well that is a fair point. But I am just trying to prevent "stop energy".
When I hear things like "I don't want to duplicate content" my stop energy
bell goes off ;-)
Post by Anne Bowtell
If everyone who's been involved in the discussion could commit to
completing at least two documentation tickets over the weekend and
encouraging someone new to join into the documentation process by
dealing with a ticket, then perhaps we'd be in a position to move forward.
Heh. If you guys let me rename the PHCs and such on plone.org, I'll start writing
docs (and fixing tickets :-).
Seriously, my book is wrapping up soon, and I very much hope to have more time to
devote to documentation "proper".
Post by Anne Bowtell
Thanks
Anne
--------------030400080905070405060401
Content-Type: text/x-vcard; charset=utf-8;
name="anne_bowtell.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="anne_bowtell.vcf"
YmVnaW46dmNhcmQNCmZuOkFubmUgQm93dGVsbA0KbjpCb3d0ZWxsO0FubmUNCmVtYWlsO2lu
dGVybmV0OmFubmUuYm93dGVsbEBtZWRzY2kub3guYWMudWsNCnRlbDt3b3JrOis0NCAoMCkx
ODY1IDg4MjgyOQ0KeC1tb3ppbGxhLWh0bWw6RkFMU0UNCnZlcnNpb246Mi4xDQplbmQ6dmNh
cmQNCg0K
--------------030400080905070405060401
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
------------------------------------------------------------------------------
--------------030400080905070405060401
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
--------------030400080905070405060401--
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
------------------------------------------------------------------------------
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
Alex Clark
2010-05-20 02:18:05 UTC
Permalink
Hi,
Post by Dylan Jay
I actually think versioning by major version is enough
e.g. documentation/manuals/plone4/developer
documentation/manuals/plone3/developer
Then how would you stage content? If you create:

http://plone.org/documentation/develop/3.0
http://plone.org/documentation/release/3.0

and:

http://plone.org/documentation/develop/4.0
http://plone.org/documentation/release/4.0

Once you release 3 and 4 (which you only do once, and don't touch after), you'd have
to wait until 5 before you could publish (aka release) again.

As far as I can tell, this amounts to shooting the doc team in the foot ;-)
At least with:

http://plone.org/documentation/develop/3.3.5
http://plone.org/documentation/release/3.3.5

and:

http://plone.org/documentation/develop/4.0
http://plone.org/documentation/release/4.0

You could create a:

http://plone.org/documentation/develop/3.3.6

and:

http://plone.org/documentation/develop/4.1

as soon as:

http://plone.org/documentation/release/3.3.5
http://plone.org/documentation/release/4.0

go out the door.

Hell, you could even release a 3.3.6 of the documentation
sans a Plone 3.3.6 (as long as we declare that it's the
documentation that *would* have been release had 3.3.6
been released).

Anyone know if there is a 3.3.6 in the works?

Alex
Post by Dylan Jay
Post by Alex Clark
Hi Anne!
Post by Anne Bowtell
OK, that's fine going forward, but what about the Plone 3
documentation.
Let it die. Unless there is a 3.3.6, in which case I'd release whatever documentation
- Of course, there are no "3.3.5 docs" right now. But you could take the existing
set of "Plone 3 docs" and release them as the "3.3.5. docs" If there are things
in that set of docs that don't apply to 3.2 or 3.1 or 3.0, then so be it. I'm
not sure I'd worry about that at this point.
- If you were to do that, then you'd continue edit the 3.3.5 docs in private until
such time as 3.3.6 comes out (if it comes out).
Post by Anne Bowtell
With respect to the theme reference manual - it does not yet document
everything that's required for Plone 3 theming. So is that just
abandoned, half-finished? There are plenty of people around still using
Plone 3.
See above, the short answer is "don't worry about it." (IMO)
Post by Anne Bowtell
Well, it's because we're aware of what needs to be done, the size of the
task ahead of us, how thin on the ground and, to a certain extent,
de-moralized the documentation 'team' is, how unfinished the current
projects are, and how much we're relying on one person (Israel) to hold
it all together at the moment. Just making big plans when what we need
to do is get our heads down and work out how to get the Plone 4
documentation required done (and all the boring, mundane tasks like
screenshots that that required) is taking a great deal of energy. This
isn't really the time for big plans.
Any time is the time for big plans IMO, but I hear you. To be honest,
I'm not so sure it would be *that* bad to release the current set of
documentation as the 3.3.5 documentation, and keep developing the 4.0
documentation "in private" until such time as it is ready. This is
open source, so people will get it when they get it. (IMO)
Remember, no one really knows what you guys are doing (IMVHO). I'm trying to
bridge the gap between the hard work that is occuring, and the
perception of the general public which is "confusing docs".
Post by Anne Bowtell
And, I can tell you, that trying to organize and structure the manual
that I put together was tough but also really important. I'm sort of
surprised that you should think that we wouldn't be concerned about
presentation and structure.
No, I understand you are concerned about that, *within* your
documentation.
What I don't understand is why you care *where* your documentation
/documentation/
vs.
/documentation/3.3.5
/documentation/4.0
And so on.
Post by Anne Bowtell
But the people who have to do the work of maintaining the
documentation,
*are* of that opinion. You mention in the previous paragraph, that
you're not willing to engage in a task or commit to a course of action
that you feel isn't appropriate - which is fair enough. But that's what
you're asking us to do.
Not quite. I'm asking that folks consider my proposal to "version"
documentation. Period. And a postcript: I'm also asking that they be
continually be aware (in the background, so to speak) that I formally
asked the PF for money to fund the documentation effort, in case it's
ever needed, or desired in the future.
That said, in terms of *actual* work you have to do, everything
I am proposing could probably be done outside the scope
of the documentation team's efforts, whatever they are. Perhaps
that is where the confusion is occuring.
- FWT
- Website team
- Evangelism
- Marketing
(Are these different?)
In short, *everyone* that does Plone is at least "loosely" concerned
about the public-facing documentation.
Of all these folks, which is everyone basically :-), it is probably safe
to say that *none* of them would want to discourage the documentation
team in any way from doing what it is doing. That is not at all what
this is about. In fact, just the opposite. I think everyone
appreciates
that we have such dedicated folks.
What this is about is "framing" and "clarifying" and "tranparency-i-
fying"
our documentation team's efforts. I could login to plone.org right now
and rename /documentation to /3.3.5, and create a /documentation folder
(not help center) and move /3.3.5 to it to create /documentation/
3.3.5.
/documentation/release/3.3.5
/documentation/develop/3.3.6
/documentation/develop/4.0
So, at this point, 3.3.5 would not get touched. 3.3.6 would get fixes
to 3.3.5 and 4.0 would receive the full 4.0 treatment.
When 4.1 approaches, you repeat the process.
I am willing to do a great many things to assist in making this
happen. I only mentioned not being willing to work on a traversal
hack because I don't fully understand how that would work. I
suspect it won't work the way I want it to ;-)
Post by Anne Bowtell
I'm demoralized enough as it is, but I have to say that yesterday I
spent the whole morning helping a colleague who wanted to build his
first content type and I simply couldn't find the information he needed
on plone.org (although I'm sure its buried there somewhere) - so I've
been writing it all up on my own website. It made no difference whether
this was Plone 4 or 4.1 - in actual fact it was Plone 3 - whatever he
did would have been pretty much relevant to both. The information he
needed just wasn't discoverable and not delivered in a format that
helped him, as an integrator, complete the task that he had to do.
That's the bigger picture and the bigger problem.
Yeah, I got questions in my class like "is all this stuff going to
be anywhere but in PP3 or your PSA book?" and I had to give them my generic
answer: there is great stuff on plone.org if you know where to find
it (e.g. a search for apache gives you
http://plone.org/documentation/kb/plone-with-apache/)
Post by Anne Bowtell
We all want a more polished Plone, but the reality is that there
fundamental things to do in building a community of documentors who
actually write documentation for end users, integrators and
developers.
Who maybe have experience in these all these roles or have
experience in
helping people in these roles. There's room for blue-skies thinking of
course, but I just don't think that right now this discussion is helping
us much.
Hmmm, well that is a fair point. But I am just trying to prevent "stop energy".
When I hear things like "I don't want to duplicate content" my stop energy
bell goes off ;-)
Post by Anne Bowtell
If everyone who's been involved in the discussion could commit to
completing at least two documentation tickets over the weekend and
encouraging someone new to join into the documentation process by
dealing with a ticket, then perhaps we'd be in a position to move forward.
Heh. If you guys let me rename the PHCs and such on plone.org, I'll start writing
docs (and fixing tickets :-).
Seriously, my book is wrapping up soon, and I very much hope to have more time to
devote to documentation "proper".
Post by Anne Bowtell
Thanks
Anne
--------------030400080905070405060401
Content-Type: text/x-vcard; charset=utf-8;
name="anne_bowtell.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="anne_bowtell.vcf"
YmVnaW46dmNhcmQNCmZuOkFubmUgQm93dGVsbA0KbjpCb3d0ZWxsO0FubmUNCmVtYWlsO2lu
dGVybmV0OmFubmUuYm93dGVsbEBtZWRzY2kub3guYWMudWsNCnRlbDt3b3JrOis0NCAoMCkx
ODY1IDg4MjgyOQ0KeC1tb3ppbGxhLWh0bWw6RkFMU0UNCnZlcnNpb246Mi4xDQplbmQ6dmNh
cmQNCg0K
--------------030400080905070405060401
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
------------------------------------------------------------------------------
--------------030400080905070405060401
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
--------------030400080905070405060401--
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
------------------------------------------------------------------------------
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
------------------------------------------------------------------------------
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Dylan Jay
2010-05-20 02:26:04 UTC
Permalink
Hi,
Post by Dylan Jay
I actually think versioning by major version is enough
e.g. documentation/manuals/plone4/developer
documentation/manuals/plone3/developer
You continually update plone4 manual until plone5 is nearing release
at which time you copy plone4 and start working on plone5.
Alex Clark
2010-05-20 02:57:01 UTC
Permalink
Post by Dylan Jay
You continually update plone4 manual until plone5 is nearing release
at which time you copy plone4 and start working on plone5.
Hmmm, I suppose you could do that. But I wouldn't do that ;-) If for no other
reason then it is confusing (to me at least) and perhaps leads to demoralization (IMO).

"Continually update plone4 manual until plone 5 is nearing release" reads to me like

"Spend a lot of time in limbo, and make people have to guess which version of Plone the
documentation refers to"

I say that based on the fact that Plone 3.0 is a lot different than 3.3.5, but maybe
I am exaggerating.

Anyway, I should also point out that you are talking about manuals and I am talking
about PHCs (as of right now).

Having beat the versioning drum to death, I would like to propose that the doc team let
the "website team" split the documentation as suggested (effectively resulting in
various branches and at least one tag).

I am starting to feel like that satisfies the most number of folks and has
the least number of drawbacks:

- current /documentation can be "frozen" in /documentation/release/3.3.5
- Israel, Anne, et al can work in /documentation/develop/3.3.6
- Israel, Anne, et al can work in /documentation/develop/4.0
- Israel, Anne, et al can work in /documentation/develop/5.0

If anyone cares, we can go backwards and create a /documentation/release/2.5.5
that is a copy of 3.3.5, with all the content not marked 3 deleted.

Thoughts?

The one drawback I can think of is that if I search for "apache" i might get
an "old" copy of the content. But if that content is in:

http://plone.org/documentation/release/2.5.5/kb/plone-with-apache/

or

http://plone.org/documentation/release/3.3.5/kb/plone-with-apache/

I imagine folks could just "figure it out" ;-) I also imagine that it would be
easy (i.e. even something I could program ;-)) to add something to PHC that would
allow it to know what the current release is (similar to PSC).

And if a URL like:

http://plone.org/documentation/release/3.3.5/kb/plone-with-apache/

was published and 3.3.5 did not match PHC's idea of the current release, the
template could insert an "info box" that said:

================================================================================
|Info (i) |
|Are you sure you were not looking for: |
|http://plone.org/documentation/release/4.0/kb/plone-with-apache/ ? |
================================================================================

Any takers? :-D

(And thank you all for continuing to listen!)

Alex
Post by Dylan Jay
------------------------------------------------------------------------------
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Continue reading on narkive:
Loading...