Hi Jean,
In preparation, we should archive the files for v3.3.x so we don't
overwrite them with the updated files. Translators may wish to have
access to these files, without them becoming a moving target.
David, how do you think this is best done in Alfresco? A separate space
under English Content > Documentation for V3.3.x with all the v3.3.x
user guide content under that, or a space under each individual guide
See below...
for v3.3.x (leaving the existing spaces for work in progress) -- for
example, English Content > Documentation > Writer Guide > V3.3.x
archives? I could make an argument for either solution.
So we'd have "English Content > Documentation > Writer Guide > V3.3.x"
and "English Content > Documentation > Writer Guide > V3.4.x"
Then we could move the Drafts, Proofread, Reviewed and Published
folders under "English Content > Documentation > Writer Guide" into
"English Content > Documentation > Writer Guide > V3.3.x", create
"English Content > Documentation > Writer Guide > V3.4.x" and
duplicate the Drafts, Proofread, Reviewed and Published folders there
for updating then.
I think that this would be the better solution from the viewpoint of
the groups and permissions we'll set up after discussing the details
on the list. Does that seem OK to you?
We can then copy those files into the Drafts spaces, update them, and
save them under different names -- to avoid confusion and to enable us
to put them on wiki along with the 3.3.x files. For example,
0101GS34-ChapterTitle.odt instead of 0101GS3-ChapterTitle.odt.
I'd love to get the versioning info out of the file name and into the
document's meta data, so that - for instance -
"0101GS34-ChapterTitle.odt" would become "ChapterTitle.odt" and that
doc's meta data contains all the info we want to store about that doc.
I remember we had a thread about this a few months ago, but we didn't
reach a final decision about it, although you mentioned a number of
items that should go in the meta data (I can dig that out when I get
time today or tomorrow).
If we did decide to do as described above, I guess it would be
rational to do it now before spawning the 3.4 docs. It would involve
renaming every doc and inserting meta data; I'm perfectly OK to take
part in that job or even do it all myself once/if we have agreed on
the meta data. I could manage in in a pre-announced and approved
one-day session, so that work does not get held up for other people.
But guys would have to check-in all checked-out docs beforehand, and
then check them out again after the process was finished.
(Alfresco can happily display a document's meta data, so it's not a
problem of not being able to identify and distinguish between
documents and versions).
What are everyone's thoughts about that?
Then, when the 3.4.x files begin to be published, they should be made
available on the wiki as well as (not instead of) the 3.3.x files,
because many people may continue to use 3.3.x for some time and need
access to the 3.3 files.
Yes, I agree... many users might not upgrade to 3.4 for quite a while yet.
Also in preparation, we need to go through the features list to see what
needs to be changed. Making a table of chapters and needed changes (on
the wiki) can be very helpful here.
Yes, I guess so... Until such time as I get alfresco.libreoffice.org
and media.libreoffice.org sorted out, I probably would not play a
major part in that...
While updating chapters, we also want to replace any remaining
screenshots with ones to match the agreed theme or that still contain
OOo-related info that was missed earlier.
So what do we decide in the end? Go with your XP silver theme? Use the
default theme from whatever distrib or OS the screenshooting person
uses? Are we agreed that Windows screenshots are OK subsequent to the
SC's kind-of pronunciation/recommendation about that? Or do we
recommend a particular theme that can be availed in Windows/Mac/*nix
versions? Or do we pragmatically accept whatever we can get from
contributors, making the "entry barrier" as low as possible?
The word "pragmatically" sort-of suggests my own POV, but I'll go with
whatever decision you and the team arrive at (unless other team
members strongly and rapidly veto your recommendation, I think we
should adopt it and move on quickly).
We also need to decide whether to go ahead with my proposed
reorganisation of the Getting Started guide and the Writer Guide -- or
perhaps with some subset of my proposal. Richard Holt is working on
changes to Getting Started, but there was some difference of opinion
about some of my suggestions on both that book and the Writer Guide, so
I'm unclear whether we're all agreed on the way to move forward. I
really don't want to see everyone sitting around waiting for a
consensus.
My own POV would be to make that a low priority or prefer to press
ahead with new stuff. But I'll be guided by what you feel is best and
+1 whatever you recommend (which I reckon we should adopt unless there
is a strong veto by other team members).
What have I missed or forgotten?
Nothing I can think of.