-
Notifications
You must be signed in to change notification settings - Fork 13
Home
The openETCS@ITEA2 project like most open source R&D projects do not have a traditional organization with a (more or less) clear top/down structure and traditional "managers" and "directors" on the top and “workers” - more on the down side - who get "managed" or "directed". OSS projects are usually in a context, which is more like a network of individuals and peer groups with their own and mostly diverse managerial structure with different management and working cultures. Working groups in such projects mostly consist of people coming from different organizations, in the best case volunteering to work in such projects. Traditional management need tree-like structures (“top/down”) to work well. It does not function too well in networks. Also such networked groups need “Leadership”, which helps to structures activities, helps to solve conflicts, get decisions made, however without the power of directing people what to do, when and in what way. In the best case they can work in a self-directed way, e.g. in self-managed groups. Studies have shown that for cognitive highly skilled technological work self-direction can result in very high performance (go there ==> "The surprising truth about what motivates us" to better understand what I mean). But even self-managed groups need some "guidance" and "rules" and that is where the “Governance” comes into play. While “Managers” make decisions, “Governance” tells people how decisions have to be made, who has to be involved and what procedures are to follow, in order to keep all decisions transparent and understandable for everyone involved and also for the outside world, which eventually may become a customer. In other words, "Governance" is to help people to get their job done in a way that everyone can understand and can follow. Compliance with “Governance” is expected to be best if those are involved, who have to follow them. Governance can start with a draft or “start value” and then gets adapted along the way by those people who need to follow that particular Governance. Since rules are not falling out of the sky, we need to develop them and therefore this is also a development project like any other development project in this overall openETCS project. This repository provides services and resources to accommodate this Governance Development.
An overview of the project progress by means of a list of all deliverables including their current state. The state information is maintained by the work package leaders and updated monthly.
For each weekly GotoMeeting notes will be taken and posted as LaTeX as well as PDF formatted documents on this repository. Comments, remarks, or any change request should be posted within 7 days after the meeting by using the issue tracker, if possible at least 24 hours before the next scum meeting in oder to address this issue during the following meeting. Otherwise the meeting minutes are considered as generally accepted.
[Project Management] (https://github.com/openETCS/governance/wiki/Project-Management)
Learning from WP7 and WP4 we now start to give an weekly overview on upcoming events and work done.
- 1st PCC (14.04.2013)
- 2nd PCC (01.07.2013)
- 3rd PCC (06.08.2013)
- 4th PCC (08.10.2013)
- 5th PCC (15.01.2014)
- 6th PCC (09.04.2014)
- 7th PCC (11.06.2014)
PCC meeting minutes and the agenda of planned meetings here. Comments, remarks, or any change request should be posted within 30 days after the meeting by using the issue tracker, if possible at least 2 weeks before the next PCC meeting in oder to address this issue during the following meeting. Otherwise the meeting minutes are considered as generally accepted.
The Quality Assurance Plan (QA Plan) is currently under development and describes working processes and all kinds of quality aspects for the openETCS project. As long as the QA plan has not yet been finalized, equivalent rules and the openETCS development process in analogy to the eclipse development process have to be applied. The QA Plan backlog provides a plan to develop the document.
One of the most important activities for quality assurance is a sound review process for all kinds of documentation, software and other artifacts generated within this project. The Review Process provides a guideline on how to deal with it. The [Revision/Review processes backlog] (https://github.com/openETCS/governance/wiki/Revision-Review-processes-backlog) provides a plan to develop the corresponding documents.
An open project lives from an active community, which provides feed back, critique, recommendations, etc. in order to improve the product or process. Therefore this project welcomes any kind of feed back. For that we have a process which relies on the GitHub issue tracker. Please provide your feed back by making use of this Issue Tracker. In order to make sure that we can identify you, you must register with GitHub and get a GitHub account. This is free of charge. If you want to contribute with larger contributions you have to register with the openETCS project office.
Guidance on how to create a wiki page to list all the available documents of a repository/project inside the wiki section of each repository. This section shall be the starting point for any person who needs to know the state of the documents contained in a repository, or needs a general overview. Guide for listing documents. The List of documents of the governance repository is in the Governance list of documents wiki page.
Guidance on how to manage and create local branches and adding contributions to a file/document contained in a specific branch using the Smartgit tool.
Guidance on how to create the configuration items naming.