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

Reply via email to