removed ESH references and added governance infos

.vuepress/docs-sidebar.js

@@ -113,20 +113,12 @@ module.exports = [
       children: [
         ['developer/', 'Development Overview'],
         'developer/contributing/contributing',
-        'developer/prerequisites/osgi',
-        'developer/prerequisites/osgids',
-        'developer/prerequisites/configadmin',
-        'developer/prerequisites/osgitasks',
-        'developer/prerequisites/eventadmin',
-        'developer/prerequisites/tycho',
-        'developer/prerequisites/equinox',
-        'developer/prerequisites/targetplatform',
+        'developer/contributing/governance',
         'developer/development/ide',
         'developer/development/guidelines',
         'developer/development/conventions', // from v2.3 onwards
         'developer/development/bindings',
         'developer/development/logging',
-        'developer/development/evolution',
         'developer/development/compatibilitylayer',
       ]
     },

developers/contributing/contributing.md

@@ -9,30 +9,30 @@ title: Contribution
 
 ## The Repositories
 
-Note that the openHAB distribution repository does not contain any source code, but it rather aggregates features from different repos:
+The main parts of openHAB can be found in the following repositories:
 
-* [Eclipse SmartHome Framework](https://github.com/eclipse/smarthome): This repo holds the major parts of the core functionality.
-* [openHAB 2 Core](https://github.com/openhab/openhab-core): This repo contains a few small bundles that are not part of Eclipse SmartHome, but required for the openHAB runtime. This e.g. contains a compatibility layer for supporting openHAB 1 add-ons.
-* [openHAB 2 Add-ons](https://github.com/openhab/openhab2): Add-ons of openHAB that use the Eclipse SmartHome APIs can be found within this repository. They cannot be used with an openHAB 1.x runtime, since they provide features that the old runtime does not support.
-* [openHAB 1 Add-ons](https://github.com/openhab/openhab): Add-ons developed for openHAB 1.x. Most of them are working smoothly on the openHAB 2 runtime and thus they are packaged within the distribution.
-* [Eclipse SmartHome Extensions](https://github.com/eclipse/smarthome/tree/master/extensions): Since openHAB uses the Eclipse SmartHome framework, it is automatically compatible with all extensions that are available for it and maintained within the Eclipse SmartHome repository. These are usually high-quality extensions that might be even used in commercial products.
+* [openHAB Core](https://github.com/openhab/openhab-core): This repo contains the core framework bundles of which the openHAB runtime is constructed.
+* [openHAB 2 Add-ons](https://github.com/openhab/openhab2-addons): Add-ons (such as bindings, voice services, etc.) of openHAB can be found within this repository. They cannot be used with an openHAB 1.x runtime, since they provide features that the old runtime does not support.
+* [openHAB 1 Add-ons](https://github.com/openhab/openhab1-addons): Legacy add-ons that were developed for openHAB 1. Most of them are working smoothly on the openHAB 2 runtime and thus they are made available for backward compatibility reasons. They are not suggested for new users, though.
+* [openHAB Distro](https://github.com/openhab/openhab-distro): This repo contains all parts that are required for assembling the binary distribution of openHAB.
+
+Besides those "main" repositories, there are a dozen further ones, which are not listed here in detail - just [check out the list](https://github.com/openhab) and you will find separate repos for openHAB Cloud, the Alexa skill, the Google Action, the Android and iOS apps, the Zigbee and ZWave bindings, HABPanel and HABot and many more.
+If you want to get involved with any of these, best check their respective README and CONTRIBUTING files in the root of the repos.
 
 ## Contribution Guidelines
 
 ### Pull Requests are Always Welcome
 
-We are always thrilled to receive pull requests, and do our best to
-process them as fast as possible. Not sure if that typo is worth a pull
-request? Do it! We will appreciate it.
+We are always thrilled to receive pull requests, and do our best to process them as fast as possible.
+Not sure if that typo is worth a pull request? Do it! We will appreciate it.
 
-If your pull request is not accepted on the first try, don't be
-discouraged! If there's a problem with the implementation, hopefully you
-received feedback on what to improve.
+If your pull request is not accepted on the first try, don't be discouraged!
+If there's a problem with the implementation, hopefully you received feedback on what to improve.
 
-We're trying very hard to keep openHAB lean and focused. We don't want it
-to do everything for everybody. This means that we might decide against
-incorporating a new feature. However, there might be a way to implement
-that feature *on top of* openHAB.
+We're trying very hard to keep openHAB lean and focused.
+We don't want it to do everything for everybody.
+This means that we might decide against incorporating a new feature.
+However, there might be a way to implement that feature *on top of* openHAB.
 
 ### Discuss your Design on the Mailing List
 
@@ -100,20 +100,16 @@ or `Fixes #XXX`, which will automatically close the issue when merged.
 
 ### Merge Approval
 
-openHAB maintainers use the [Github review feature](https://help.github.com/articles/about-pull-request-reviews/) to indicate acceptance.
+openHAB maintainers use the [GitHub review feature](https://help.github.com/articles/about-pull-request-reviews/) to indicate acceptance.
 
-A change requires approval from an absolute majority of the maintainers of each
-component affected. For example, if a change affects `addons/` and `features/`, it
-needs an absolute majority from the maintainers of `addons/` AND, separately, an
-absolute majority of the maintainers of `features/`.
 
 ### Sign your Work
 
 The sign-off is a simple line at the end of the explanation for the
 patch, which certifies that you wrote it or otherwise have the right to
 pass it on as an open-source patch.  The rules are pretty simple: if you
 can certify the below (from
-[developercertificate.org](http://developercertificate.org/)):
+[developercertificate.org](https://developercertificate.org/)):
 
 ```
 Developer Certificate of Origin
@@ -180,9 +176,10 @@ There are several exceptions to the signing requirement. Currently these are:
 
 * Step 1: learn the component inside out
 * Step 2: make yourself useful by contributing code, bugfixes, support etc.
-* Step 3: volunteer on [in the community] (https://community.openhab.org/)
+* Step 3: volunteer [in the community] (https://community.openhab.org/c/development/misc) or in the appropriate GitHub project and have a [maintainer](governance.html#maintainers) [nominate you](governance.html#nominations).
 
-Don't forget: being a maintainer is a time investment. Make sure you will have time to make yourself available.
+Don't forget: being a maintainer is a time investment.
+Make sure you will have time to make yourself available.
 You don't have to be a maintainer to make a difference on the project!
 
 ## Community Guidelines

developers/contributing/governance.md

@@ -0,0 +1,80 @@
+---
+layout: developersguide
+title: Governance
+license: Parts of this page have been derived from the EPLv2 licensed https://www.eclipse.org/projects/handbook
+---
+
+{% include base.html %}
+
+# Governance of the openHAB Project
+
+## Principles
+
+The guiding principles for openHAB are the "open source rules of engagement", which comprise:
+- Transparency
+- Openness
+- Meritocracy
+
+To operate with transparency, discussions, minutes, deliberations, project plans, plans for new features, and other artifacts are open, public, and easily accessible.
+
+Openness means quite a lot more than "open book" (which is really a synonym for transparent). The project is open to all; openHAB provides the same opportunity to all. Everyone participates with the same rules; there are no rules to exclude any potential contributors.
+
+openHAB is a meritocracy. The more that somebody contributes, the more responsibility they will earn. A pattern of quality contribution may lead to an invitation to join the project as a maintainer. Leadership roles are merit-based and earned by peer acclaim. Merit must be demonstrated in publicly-accessible activities. Maintainers are added to a project via election.
+
+## Structure
+
+The openHAB project is a big ecosystem of different components.
+While people often think of the runtime + addons when talking about openHAB, there are other parts like openHAB Cloud, the mobile apps, the voice skills, etc. - all in all, there are well over [40 different repos](https://github.com/openhab) under the openHAB GitHub organisation.
+
+The different components are mostly maintained independently of each other. Many have their own release cycles and a dedicated maintainer team.
+
+## Maintainers
+
+The [maintainers of openHAB](https://github.com/orgs/openhab/teams/maintainers) is the superset of [all maintainers of the different code repositories](https://github.com/orgs/openhab/teams/maintainers/teams).
+This means that the maintainer role is always related to a certain repository/component only and not to the entire project as such.
+
+Every component can (and should!) have more than one maintainer. All maintainers of a given repository build the maintainer team of the component in this repository.
+
+The maintainers are the ones with write access to the repository and they are responsible for the source code, the proper processing of PRs against the repo and the overall evolution of the code base.
+
+### Responsibilities
+
+Maintainers take care of the respective repository, i.e. they
+- define coding guidelines
+- decide the architecture and features of the code
+- review PRs
+- process and answer issues
+- deal with releases
+- sync with other maintainer teams wrt cross-team changes
+- announce important news in the community
+
+In general, a maintainer team is free to define its own rules of how the work in the team is organised, e.g. what is required for a PR to be accepted. Those rules should be written down as a pinned discussion on the GitHub team page, see [this one](https://github.com/orgs/openhab/teams/2-x-add-ons-maintainers) as an example.
+
+A [couple of rules](https://github.com/orgs/openhab/teams/maintainers/discussions/1) must be followed by all maintainer teams, they ensure that there's some consistency in the workflows across the different repositories.
+
+### Maintainer Elections
+
+Contributors who have the trust of the component’s maintainers can, through election, be promoted to maintainer status for that component. The breadth of a maintainer's influence corresponds to the breadth of their contribution.
+
+A maintainer gains voting rights allowing them to affect the future of the project. Becoming a maintainer is a privilege that is earned by contributing and showing discipline and good judgment. It is a responsibility that should be neither given nor taken lightly.
+
+#### Nominations
+
+A maintainer nomination should explain the candidate’s contributions to the component and thus why they should be elected as a maintainer. Cite the issues they have fixed via PRs; cite the community forum postings they have answered; cite the design discussions to which they have contributed; etc. In all cases, provide urls to source material.
+
+Only the component's maintainers may nominate a new maintainer or vote in a maintainer election. To be successful, the election must receive a minimum of three positive +1 votes. Any maintainer can veto the election by casting a -1 vote. For components with three or fewer committers all maintainers must vote. Maintainer elections run for one week, but will end prematurely if all project committers vote +1.
+
+Nominations must be done on the GitHub team discussion page (as a public post) and voting is done through _reactions_ on that post.
+
+#### Ending Maintainership
+
+A maintainer can resign from the maintainer role at any time without specifying reasons.
+Maintainers that are inactive for more than 3 months can be excluded from the maintainer team through a vote by the other maintainers which concludes without a veto after one week.
+
+## Architecture Council
+
+The [openHAB Architecture Council](https://github.com/orgs/openhab/teams/architecture-council) serves the community by identifying and tackling any issues that hinder openHAB’s continued technological success and innovation, widespread adoption, and future growth. This involves technical architecture as well as open source processes and social aspects. Comprising the finest technical leaders from all community stake holders, it is the council’s goal to keep the project successful and healthy, the processes simple and smooth, and the communities vibrant and cohesive.
+
+The Architecture Council is responsible for all decisions that have a significant impact across different components and which touch any fundamental concepts how openHAB works and behaves.
+
+Membership rules for the Architecture Council t.b.d. soon!

developers/development/bindings.md

@@ -5,43 +5,30 @@ title: Developing bindings
 
 {% include base.html %}
 
-# Developing a Binding for openHAB 2
+# Developing a Binding for openHAB
 
-This page describes the necessary steps in order to implement a new binding for openHAB 2.
-
-_Note:_ Please note that in contrast to openHAB 1.x, openHAB 2 is based on the [Eclipse SmartHome](http://eclipse.org/smarthome/) project.
-So the APIs and concepts have changed, so please read this documentation carefully, if you are coming from openHAB 1.x development.
+This page describes the necessary steps in order to implement a new binding for openHAB.
 
 For information about code style and naming conventions, please see the [coding guidelines](guidelines).
 
-## Choosing a Namespace
-
-As a first step, you need to decide in which namespace you want to develop your binding - assuming that you want to contribute it back to the community, you have two options:
-
-* You can choose `org.eclipse.smarthome`, if you want to directly contribute it to the Eclipse SmartHome project.
-The advantage of this option is that you make it available to a wider audience as your binding will also be available for other solutions than openHAB that are based on Eclipse SmartHome.
-The disadvantage is that the contribution process is stricter as it involves intellectual property checks and in general makes it harder or even impossible to include third-party libraries with copy-left licenses such as LGPL or code that you have written by reverse engineering some protocol.
-* You can choose `org.openhab`, if you want it to be used for openHAB only.
-This is the better option, if your binding is not interesting for other solutions, requires special libraries or has technical dependencies on openHAB specific things (although this should be avoided as much as possible).
-
-## Creating a Skeleton
-
-For the openHAB namespace: Choose the option "openHAB 2 Add-ons" in [your IDE setup](ide.html), and create a skeleton for your binding.
-To do this, go into your Git repository under `git/openhab2-addons/addons/binding` and call the script `create_openhab_binding_skeleton.sh` with two arguments.
+Choose the option "openHAB 2 Add-ons" in [your IDE setup](ide.html), and create a skeleton for your binding.
+To do this, use a command line terminal and go to your Git repository folder under `git/openhab2-addons/addons/binding` and call the script `create_openhab_binding_skeleton.sh` with two arguments.
 It is important that your binding name is in camel case (e.g. 'ACMEProduct' or 'SomeSystem').
 After the binding name, provide your name as the author (surrounded by quotes if you want to use whitespaces to separate your first and last name).
 Example: `~/git/openhab2-addons/addons/binding/create_openhab_binding_skeleton.sh BindingName "Firstname Lastname"`
 
-For the Eclipse SmartHome namespace: Choose the option "Eclipse SmartHome Extensions" in [your IDE setup](ide.html), and create a skeleton for your binding.
-To do this, go to `git/smarthome/tools/archetype`and run `mvn install` in order to install the archetype definition in your local Maven repo.
-Now go to `git/smarthome/extensions/binding` and call the script `create_binding_skeleton.sh` with two parameters.
-The first one is your binding name in camel case (e.g. 'ACMEProduct' or 'SomeSystem').
-The second one is your name as author (surrounded by quotes if you want to use whitespaces to separate your fist and last name).
-
-Now switch back to Eclipse and choose `File->Import->General->Existing Projects into Workspace`, enter the folder of the newly created skeleton as the root directory, and press "Finish".
+Now go back to the IDE and choose `File->Import->General->Existing Projects into Workspace`, enter the folder of the newly created skeleton as the root directory, and press "Finish".
 
 _Note:_ Here you can find a [screencast of the binding skeleton creation](http://youtu.be/30nhm0yIcvA).
 
+## Before You Start
+
+If you plan to contribute your binding to openHAB through a PR, here is what we suggest to help keeping the potential effort for changes due to reviews low:
+
+- Before you start with the implementation, create an issue on GitHub and talk about your plan to come up with a PR. Maybe there are others that have privately a similar binding before and would be ready to contribute it. Also, it might help finding collaborators for the implementation.
+- It is a good idea to start with modelling the Things for your binding, i.e. what kind of Bridge-Types, Thing-Types and Channel-Types it should have. Also, you should create the classes for the handlers that you need as well as potential discovery services (but no need to implement any working code at that stage). With this in place, you are invited to already create a PR and mark it as [WIP] (for: work in progress) and ask for a first review. You might get valuable input from maintainers and other experts and you avoid having to refactor all details of an implementation.
+- Once the general architecture/modelling of your binding is approved, go for the implementation details and ask for a final review in the end.
+
 ## Implement the Binding
 
 The skeleton should give you an easy starting point for your developments.
@@ -51,12 +38,6 @@ Please especially note our [coding guidelines](guidelines), which must be respec
 If you have any special dependencies in your code, please check the [library recommendations](https://www.eclipse.org/smarthome/documentation/development/bindings/dependencies.html) at Eclipse SmartHome.
 This will ensure that everyone uses the same libraries for e.g. JSON and XML processing or for HTTP and websocket communication.
 
-_Note:_ Currently Eclipse SmartHome and openHAB use different license texts.
-The skeleton template refers to SmartHome, while it should refer to openHAB.
-To compile a new openHAB binding without errors, you have to perform the following additional steps:
-
-- run `mvn -pl :<binding artifactId> license:format` in the root folder of your local Git repository (see [coding guidelines A.2](guidelines.html#a-code-style))
-
 ## Setup and Run the Binding
 
 To setup the binding you need to configure at least one *Thing* and link an *Item* to it.
@@ -97,9 +78,9 @@ mvn clean install
 from the repository root to ensure that the build works smoothly.
 If it does, it is time to [contribute your work](../contributing/contributing.html)!
 
-### Static code analysis
+### Static Code Analysis
 
-The Build includes [Tooling for static code analysis](https://github.com/openhab/static-code-analysis) that will validate your code against the openHAB Coding Guidelines and some additional best practices.
+The build includes [Tooling for static code analysis](https://github.com/openhab/static-code-analysis) that will validate your code against the openHAB Coding Guidelines and some additional best practices.
 Information about the checks can be found [here](https://github.com/openhab/static-code-analysis#esh-guidelines-covered).
 
 The tool will generate an individual report for each binding, which you can find in `.../your_binding_directory/target/code-analysis/report.html` file and a report for the whole build that contains links to the individual reports in the `../openhab2-addons/target/summary_report.html`.