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?
Why do we need to preserve the 4 subspaces for the archived docs? I
don't have any objection to doing so; just wondering about your reason.
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.
Okay with me, as long as I'm not doing the work.
> 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?
I think the consensus was: recommend, but not require, the "Ubuntu
XP-Silver" theme. A similar-looking theme on other platforms is okay,
but over time we'd like to replace non-standard images with those from a
single platform/theme. I think this meets the "pragmatic" requirement
(with which I agree) but works towards a more professional-looking
result.
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).
Two items I suggested can be done fairly quickly (dropping the "Creating
Web Pages" chapter and the "Keyboard Shortcuts" appendix from Getting
Started), but other items would take more work and/or are controversial.
So at this point I think it's best to do only those two changes while
updating the factual info for v3.4.x. That's assuming, of course, that a
full set of files for 3.4.x is the way to go, instead of what Nino has
just mentioned, which I'll return to in another note.
Also, *not* split the Writer Guide, since that was controversial. Time
constraints may also mean not adding new chapters (that is, any that
need to be written) to the Writer Guide on this update cycle. Work on
them, yes; get them ready for the following update cycle. But don't hold
up the book to get them in.
--Jean