Ok, then better do this. It is about writing new Documentation and maybe use some shortcuts to base some of the documentation on LO Documentations.
https://creativecommons.org/licenses/by-sa/3.0/ On 11.02.19 21:35, Dave Fisher wrote: > Hi - > > Are we discussing old documentation or new documentation? > > Which version of CC-BY-SA? > > I’ve seen opinions in LEGAL JIRAs that website and documentation are all > Apache product so we need to follow the rules on > https://www.apache.org/legal/resolved.html and ask questions on > legal-discuss@ if we want clarification. > > Regards, > Dave > >> On Feb 10, 2019, at 4:21 AM, Mechtilde <o...@mechtilde.de> wrote: >> >> Hello Peter, >> >> to have no trouble later we should define the license for the documentation. >> >> i prefer CC by-sa >> >> Kind regards >> >> Mechtilde >> >> Am 10.02.19 um 13:04 schrieb Peter Kovacs: >>> Hi all, >>> >>> I am not sure who is working on documentation and what targets you guys >>> have. >>> >>> I have now a rough Overview on OpenOffice from the Bugzilla side. I feel >>> the need to create a documentation, since I feel very lost in the code. >>> And I really do not understand the coding decisions. I would do it all >>> differently. >>> >>> And I would like to start to use the mwiki for architectural/development >>> Documentation. I very much dislike the documentation how it has been >>> done so far. It is spiked with names, project, todo lists, concepts, >>> documentation and Ideas of all kind. >>> >>> Names and Responsibilities: >>> >>> I would like to remove all naming who is responsible for what on >>> mwiki. This view is long gone and some of the ideas read like the >>> responsible people have created their own project in the meanwhile. >>> So for me it feels more like a grave. If anything of this has any >>> meaning we should move it to the cwiki, separating the Software from >>> its Management. And management should be about doing something and >>> not writing what someone took responsibility to do. I think it is >>> not how we want to work. >>> >>> Todos, Tasks and Bugs, Ideas >>> >>> If those still apply Todos / Tasks Imho should be moved to Jira. >>> Bugs and Issues should move to Bugzilla. >>> >>> I really do not care much if they end up all in BZ. Mwiki is the >>> wrong place, that is the main argument. And Jira I want to use for >>> the road map planning, so task base view is good there. And I link >>> Bugzilla anyhow. >>> >>> >>> Documentation goal: >>> >>> What I target at is to move all the remaining stuff in a new View. >>> Starting with an overview page explaining an overall picture, >>> defining words we use, shortcuts that one can find. >>> Then describe each module, where a module is one folder under main. >>> What it is goal, features it provides, an Source file based UML-Chart. >>> I would also like to start another view of use cases. Each use case >>> describes something from users perspective. It does not need to be >>> strict. I.E. UI considerations we already have can remain as is in >>> the Use case section. Only importance is that it is as technical >>> unspecific as we can describe it even we know how we implement it. >>> Also I would like to add concepts into the use-case, but rewritten >>> on use case level pushing the concrete Idea how it could be done to >>> a later moment. >>> >>> There are other Views, like startup description and other things >>> that we can reuse and do not fit in the views above. We still can >>> keep these as additional things. >>> >>> To be clear the documentation should be in a way that it does not >>> cause to much of maintenance. Biggest issue of documentation overall. >>> >>> I hope my words make any sense to you. I tried to write as specific as I >>> am able to, but I have not made my mind up what the result exactly will >>> be. So probably I have some iterations until I am happy on the contents >>> and can better describe what I think needs to be documented. I learn as >>> I crouch forward. I welcome any participation or insight or >>> recommendation you want to give. >>> >>> Are there concerns, Objections, Ideas or doubts I need to look into >>> before I start? I have some fears toi simply remove names. I do not want >>> to hurt people that they might loose their Kudos. (Imho they do not) >>> >>> All the Best >>> >>> Peter > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org