Hi Dennis On 2/3/2021 12:06 PM, Dennis Hamilton wrote: > There is only one project for all of it, so it is not clear how well > the handling of multiple guides and other publications can be > sequenced and synchronized. Unfortunately, a check-out at this level > will bring everything to a contributor's computer. I don't know if > there is a finer-grained way to handle this. It would be worth > investigating. Most top-level GitHub projects provide multiple > (sub-) projects so coordination is better. However, > github.com/apache/ is that level so such capability is already taken > [;<). >
The logic behind using branches with the 2 directories is to handle the draft->edit cycle prior to publication. The same person cannot be author and editor on the same document or chapter. Using the Review folder for that initial cycle helps alleviate that issue. > A subdirectory structure that has a folder for each guide or other > publication, and maybe folders on templates and other materials for > authors/editors would be helpful. If these are actually (sub-) > projects, working is even easier. There could still be subfolders on > released, draft, or however you want to do that. > I am not understanding your use ob sub-projects here Dennis.According to the GitHub documentation, a sub-project developed outside of the main project and pulled in as needed, thus alleviating the need for the project to maintain the code itself. That would not be the case here, as we are maintaining the docs in house. > It is possible to **label** *releases* rather than use branches for > that purpose. Also, it is better to branch at the individual > document level, so maybe the branch name would specify what guide is > being worked on in that branch. When a document continues to be > applicable to a newer release, one could simply tag it for that > release as well. There will need to be ground rules about this that > are clear enough people don't do pushes against the wrong branches, > etc. The value is that you don't have to update all the documents > for every dot-dot-release and interested parties can look at just the > Getting Started, or the Writer document or whatever, and know what > multiple releases the current one applies to. You may need to have > language as part of the substructure also, not just platform, however > those varieties are to be handled. > I can see branching at the software version using a branch for each guide, but it would still require 2 sub-folders to separate the in-process things from the published material. Also folders for translations are not something I had thought of. > Sometimes, when the impact of a release is minor, one might one to > provide a companion supplement to a full guide, also tagged for that > release. Supplying errata is also a good idea. > > There are many GitHub projects that can be inspected for how this > sort of thing is done. < https://github.com/MicrosoftDocs> is one > example although I think the organization can be more thoughtful when > focus is on AOO docs. Carl Marcum must know of some approaches > related to work he has done. > > If you have the rights, you can also enable Issues, Discussion and > even Wiki for the openoffice-docs project. You can then work out > matters there in a form that is easier and more organized than using > docs @ oo.a.o threads as a coordination mechanism. I am not sure of these but do warrant a discussion with infra as to the possibility of using some. Regards Keith > > Happy day-after USA Ground Hog Day. We have passed to the other > side. > > - Dennis > > PS: I still think you need to look at and consult Community Forum > folk. There is a significant amount of experience there and it is > almost all (power-) user facing. > > > -----Original Message----- From: Keith N. McKenna > <keith.mcke...@comcast.net> Sent: Wednesday, February 3, 2021 07:20 > To: doc@openoffice.apache.org Subject: Repository has been created > > I got word earlier from Carl Marcum that the repository > https://github.com/apache/openoffice-docs has been created. It is > pretty sparse at the moment as there is only the README.md file from > my repo on GitHub. > > The next step is to define the the branches. Do we want a separate > branch for each release of the the software for example 4.1.9, 4.1.10 > or just for the major.minor, for example 4.1, 4.2 etc. > > The branch for each release has the potential to create more work in > that we could be creating new documentation that has few if any > changes to the previous versions. > > The major.minor branching creates the reverse possibility. We could > **not** produce documents when it was warranted. > > Please reply with any suggestions for either of the schemes above and > if you have an idea for something else. > > Regards Keith > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: doc-unsubscr...@openoffice.apache.org > For additional commands, e-mail: doc-h...@openoffice.apache.org >
signature.asc
Description: OpenPGP digital signature
