You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Peter Kovacs <Pe...@Apache.org> on 2019/02/10 12:04:09 UTC
Documentation of OpenOffice
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
Re: Documentation of OpenOffice
Posted by Matthias Seidel <ma...@hamburg.de>.
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
>
>
>
Re: Documentation of OpenOffice
Posted by Peter Kovacs <Pe...@Apache.org>.
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 <oo...@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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Documentation of OpenOffice
Posted by Dave Fisher <da...@comcast.net>.
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 <oo...@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Documentation of OpenOffice
Posted by Mechtilde <oo...@mechtilde.de>.
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