Documentation refresh & optional training

[leRoe93]

I would like to add some enhanced documentation to the project. For example package-info for each package to denote its actual purpose at least.

Furthermore I will draw a graph that tries to cover all relevant stuff from the VISAB project so all team members have an easier entry point for any kind of task (I also need to have a deeper look into some stuff from @VocalTrance haha).

@TimKuno @Marshmellow24 @vanessas97

Please discuss within this issue, which kind of things across VISAB may seem unclear and we should get rid of some barriers.

If somebody wants it, we could also again do some kind of refreshing training on VISAB / VisabConnector (C#) / VisabConnector (Java) to cover stuff which appeared additonally during the last weeks.

To sum up: The outcome will be an enhanced documentation within the VISAB project as well as some UML-style graph pointing out relevant structures and workflows.

[mfroeh]

Would love to help you with that.

If somebody wants it, we could also again do some kind of refreshing training on VISAB / VisabConnector (C#) / VisabConnector (Java) to cover stuff which appeared additonally during the last weeks.

I would also love that and would have proposed that much earlier if I knew you guys had the time for it. I think currently, pinpointing where you can start is really hard to do it and could be cleared up by documentation aswell as a "workshop" or something. If you guys @leRoe93 @vanessas97 @TimKuno @Marshmellow24 are up for some explaning (preferably, you present something that you want to implement and I present what solutions VISAB already has for that and where it would fir into(package wise)) I would love to help with that.

[leRoe93]

Good idea, I would suggest to discuss this more in detail tomorrow.

Once we overhauled documentation across the whole VISAB project we can have this workshop where everyone at least proposes a conceptual approach to solving his/her assigned issue for bugfixes / features / enhancements and we can discuss together where and how it would make sense to implement it.

This way we should be able to erase most of uncertainties and enable the whole group to contribute meaningfully in a previously aligned style / pattern / structure. :)

[mfroeh]

Some information on the type names I chose, that might be helpful for documentation.

• Types starting with I are always interfaces (e.g. ISessionListener<>)
• Types ending with Base are always abstract classes, as base implementations of an interface (e.g. SessionListenerBase<>). Instead of fully implementing an interface yourself, you can instead extend these classes as a baseline.
• Types starting with Basic are always instantiable classes that are either extending a Base class or implementing an interface (e.g. BasicRepository or BasicVISABFile). Basic classes, do not implement functionality beyond what is required by their interface or abstract parent class.

[mfroeh]

Adding to my previous comment.

• Types beginning with Default are implementations for games, that dont have an implementation yet in VISAB. E.g. DefaultSessionListener will be used when a game is allowed in the settings, but does not have a ISessionListener implementation yet.