Documentation of OpenOffice

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Documentation of OpenOffice

Peter Kovacs-3
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


Reply | Threaded
Open this post in threaded view
|

Re: Documentation of OpenOffice

Mechtilde Stehmann-2
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


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Documentation of OpenOffice

Matthias Seidel
In reply to this post by Peter Kovacs-3
Hi Peter,

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.

Just look at the date when these pages were last edited.
Most of them will be untouched for years, like most of the files in our
source code... ;-)

Overall, I have no objections against updating the Wiki.

Regards,

   Matthias

>
> 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
>
>
>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Documentation of OpenOffice

Dave Fisher
In reply to this post by Mechtilde Stehmann-2
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Documentation of OpenOffice

Peter Kovacs-3
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]