|
|
| Line 5: |
Line 5: |
| | | | |
| | <br/> | | <br/> |
| | + | |
| | | | |
| | | | |
| | = Glossary = | | = Glossary = |
| | + | http://wiki.openmod-initiative.org/wiki/Category:Glossary |
| | | | |
| | '''Just having a look'''<br/> | | '''Just having a look'''<br/> |
Revision as of 10:15, 9 June 2016
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
http://wiki.openmod-initiative.org/wiki/Category:Glossary
Just having a look
The user, who visits the glossary just to have a look, finds the given terms in alphabetical order. With a click on a 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 results 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” (see also).
Quality criteria
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, plausability tests passed, 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: …plausability tests passed...,...
- Open Source Code: additional to the criteria for good models: good code documentation, coding guidelines and developer documentation, ...
Specifications / explanations are also given here. The user can also participate in the discussion process.
Implementation:
Wiki pages.
openmod Activities / Events
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
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
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)
- using git for collaborative work on documents and papers (including links to good tutorials like this one)
- (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 what didn't work
Implementation:
Wiki pages.
Coding Rules / Guidelines / Standards
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.
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.
