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

Reply via email to