(http://wiki.openmod-initiative.org/ or http://platform.openmod-initiative.org/wiki)
The wiki provides information as well for non-modellers or newbies in the modelling field as for model developers. The presented information is developed collaboratively (i.e. discussions in the background).
Glossary
Use Case of all users:
Just having a look
The user, who visits the glossary just to have a look, finds a list of all terms given in alphabetical order. With a click on the term she/he gets to a wiki page showing the term and its definition as well as, if existing, its sub-terms and other related terms (ontology).
Searching a definition
The wish to clarify the terminology is not limited to beginners and non-modellers, because some terms might be used differently or be vague. A user studying a fact sheet might come across a term, that can be hardly interpreted. In order to get to know, how a term is used and understood in the openmod community, the user types the term into a search field and selects the glossary search. The search results will list all glossary entries whose titles or explanations match. With a click on one of the search result the user gets to the wiki page of the selected term.
Giving and discussing a definition
A logged-in user can on the one hand create a new glossary page in the wiki in order to give a definition of a new term. On the other hand she/he can participate in the discussions belonging to existing glossary entries as well as she/he can change the glossary entries themselves.
Implementation:
The glossary is made up by the wiki pages, which are part of the category called “glossary”.
Quality criteria
Use Case of all users:
As a result of an ongoing discussion process (in the openmod wiki or another specified place) the user finds quality criteria for data, assumptions, models, scenarios and open source code in the openmod wiki. For example:
- Data: source provided, reliable source, licence given, structure of data (i.e. machine readability etc.), ...
- Models: external validation, active community, up-to-date and good documentation (see also here), good model presentation incl. giving an overview of available extensions etc. There is a certain overlap with the elements of the model fact sheet, but here the best practice is presented / discussed.
- Assumptions: ..
- Scenarios: …
- Open Source Code: additional to the criteria for good models: good code and developer documentation, ...
Specifications / explanations are also given here. The user can also participate in the discussion process.
Implementation:
Wiki pages.
openmod Activities / Events
Use Case of all users:
As up to now the user finds here the wiki pages for the past and coming events of the openmod initiative with links to the protocols and presentations.
(Hint: The upcoming openmod workshop will also be presented on the main page (“Connect!”).)
Implementation:
Wiki pages as before.
Open Licences
Use Case of all users:
On this wiki page the user finds, as before, information with regard to open source licences, copyrights and copylefts.
Implementation:
Wiki pages as before.
Best practice guide for collaborative modelling
Use Case of model developers:
On these wiki pages the user finds a selection of tools, energy system modellers recommend / use for the collaborative open source model development. Moreover, proven work flows are presented by users for users, for example:
- Designing communication channels for a project
- Usage of issues and labels on GitHubs / issue management
- (git work flows)
- (regular) web conferences / chats and their rules (e.g. discussing points on the agenda / problems only based on existing suggestions / solution porposals)
- Good real-life meetings (incl. organising events for the developer community like http://t3board15.typo3.org/)
- Writing good protocols (documentation of agreements)
- Roles in the collaborative open source model development (lead developer, release lead etc.)
- Decision making processes
- Asking the community (mailing list or Question and Answer (Q&A) on Stack Overflow with preferred tag)
- perhaps also presentation of negative examples
Implementation:
Wiki pages.
Coding Rules / Guidelines / Standards
Use Case of model developers:
The model developers document and discuss their rules / guidelines for the coding of energy system models and their components on these wiki pages in order to establish good practice and perhaps to facilitate the process of model integration (see also here). The model developers might use the annual openmod workshops to collaboratively develop these best practice standards for software design.
Differentiation between Coding Rules / Guidelines published by oemof (e.g. git braching model) and by the OpenEnergy Platform required!
Examples for modelling with Python could be:
- PEPs (Python Enhancement Proposals): PEP 0008 for the main text and PEP 0257 for docstring conventions
- Using pylint for Python models to check the quality of the model code
- (Python 3.5 standard because of the type hints)
Implementation:
Wiki pages.
