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
Description: S/MIME Cryptographic Signature
