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
