openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Seidel <matthias.sei...@hamburg.de>
Subject Re: Documentation of OpenOffice
Date Sun, 10 Feb 2019 14:19:04 GMT
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
>
>
>


Mime
View raw message