The Future of openHAB

Here is one volunteer :smile:

How would you like us to notify that a review is done? Small comments like you do, and after the review comments are incorporated by the author, a “LGTM” comment with a notification to you? Or setting a label “ready-to-be-merged” on the pr?

1 Like

The jenkins way is to have the original author work on his repo until something is presentable, and then fork that into the main organisation by a robot. Afterwards, the original author gets push permissions to that repo.

We could add any levels you like, for example allowing only PRs which have to be reviewed and approved, much like it is now, only with the difference that addons live in their own repositories.

After a developer gains enough fame and sense of code quality, give him push rights


Cool :smile:
Well, in order to not have two people reviewing the same PR, the first thing to do is to have a PR assigned to you.
So my suggestion would be that you leave a comment on the PR you would like to help out on and @teichsta makes sure that it is assigned to you. And then, yes: Check the code against the guidelines and leave comments for the author. Btw, if you are good in automation scripts, you might want to create a separate topic to discuss about what of the review could be automated. I think there are many possibilities, like checking license headers, JavaDoc, illegal package imports etc.

great news!

yes and please be polite and respectful

as soon as you give a hint which PR your are going to review i’ll assign to you and set the “review-in-progress” label. Good look with your first binding review @hakan. Let me know if you have questions. Questions around binding reviews should be discussed here in the community. Please tag your thread with “review” and invite me to the discussion.

Thanks again, Thomas E.-E.

Hi,

I have bootstrapped a “gemeinnĂŒtziger e.V.” some years ago. One crititcal thing to consider is the goal of the organisation - there is a fixed list of organisation purposes that you must fulfill in order to reach charity status. If you need help doing this, especially in terms of a “Satzung”, please don’t hesitate to contact me.

-Mathias

@gonium Thanks for the hint. Yes, I have seen that there are rather fixed templates that have to be used. Will come back to you when thing get more concrete.

I would agree about the non-profit judicial status. Certain things are likey less “business” oriented, but I’d say that it is the best suited approach to an open source community driven initiative.

I just read an article by a guy called Martin Fowler on Design Stamina Hypothesis; it talks in part about technical debt acrued through software design (or lack thereof). I agree with what he is saying, but beleive that this concept goes much farther, as running a project or a business isn’t just about software development, and ALL parts of an organization need to be aligned in order to optimally design and deliver solutions. A business case that ever-so-slightly misses the mark, coupled with a great dev. team and good software design doesn’t mean that the project will be successful.

Which leads me to my pondering
 idea
 could certain supporting organizations lend other types of resources which could assist, strengthen, and enable the core team to be more effective and productive? Examples of what I am thinking are business/management consulting (the model/design of the org./project to work with as little friction with its parts as possible), project management (this is a job in itself), legal counsel (for the organization structure change). I’m sure a certain phone company would be able to justify allocating some more man/woman-hours to the project. :smile:

I agree that the whilst the docs are a big help, but they are also a big problem.

Especially when it should be the definitive “voice” and resource.

The apt-get install is a prime example as it is always plagued with issues https://github.com/openhab/openhab/issues/1429 but to most users, especially new ones. It is seen and should be seen as the “Apple/Play Store” and things that come from it, should be up to a working standard.

Because as interesting as it is, and whilst I obviously appreciate that putting “things on screens” is complicated. This readme is more than a little confusing :smile:

https://github.com/openhab/openhab/blob/master/distribution/src/deb/Readme.txt

Curiously I started messing around with migrating the wiki to a docs based system a few weeks bac, but still keeping the process relatively automatic. The Github Wiki is beautifully simple, but by only allowing one level of navigation, is a little too simple

I had some success using both Jekyll and Readthedocs. I can send dev links if you PM, they are obviously not for production yet.

I do think there should be some sort of styleguide about wiki entries, to cover use of markdown and tone of voice. I am happy to help with this (I am a front end designer/developer). There are a lot of assumptions made about the knowledge of the reader in the current docs. Even if we don’t cover the basics every time, we should reference where the user can find out about the assumed thing
 (if that makes sense)

Ideally for each pull request or binding, part of the code review should include the docs and making sure they have been updated and reviewed.

1 Like

I would second hakan’s suggestion. Maybe you should consider ranking add-on “owner” and not the add-on itself. I would think that this might scale better. If you assign an owner per repo, then as the owner proves that they can follow the same governance and code reviews that you would expect, you raise his/her ranking. This way, you are not acting as a bottleneck for code review, but still have a high degree of confidence that committed code is adhering to strict standards for owners with Rank 1 standings.

I think, that it is a good idea to better involve the community, but I am not sure, if a “gemeinnĂŒtziger e.V.” is the best legal entity to do this. There are some liability issues for the board of a e.V. which I thought you wanted to avoid with founding a UG.

Maybe there should be two entities, one wich protects against liability questions and one to collect financial support for openHAB. This issue needs some thought.

And just to mention it: Maybe a “gemeinnĂŒtzige GmbH” is suitable.

This is something I would love to see as well - therefore I think that not only individuals should be allowed to become members of such an organization, but companies as well. Nonetheless, I think this is a difficult path as I would want to avoid that anybody with specific commercial interests influences the project for his own benefit.

What makes you so sure? As long as companies do not have any direct business value from such an investment, I doubt that it will be easy to have them allocating resources for an “idealistic” project.[quote=“sam, post:28, topic:4048”]
I had some success using both Jekyll and Readthedocs. I can send dev links if you PM, they are obviously not for production yet.
[/quote]

I would be interested in your results there. Btw, there is a guide in German at readthedocs already: https://openhabdoc.readthedocs.org/de/latest/. I like this website/tool, but I am not sure if it is something one should be dependent on for the main documentation. I therefore rather prefer Jekyll with our own hosting of the generated documentation in the end.

I think you are missing my main point here: A person who proves that he knows about all relevant guidelines, the architecture and the legal issues does that by successfully reviewing the code of OTHERs and thus the other contributions are the ones who are good and can be trusted, once all review comments are incorporated. This person is then clearly a good maintainer and these are the people I am looking for. Nonetheless, his own code would still have lowest rank as long as no other maintainer reviewed it - the 4-eyes principle is imho very important.

Well, this adds a lot of additional work on the project - already running the UG involves a lot of efforts that are not directly related to moving the project forward, but which are purely administrative.

This is actually what we had planned for the UG, but the tax authorities are not really willing to go this way.
Anyhow, the problem that it isn’t scalable would remain. You cannot easily add members and re-assign the responsibilities among them.

I just found this on the web:
Kurzleitfaden VereinsgrĂŒndung - GrĂŒndung eines e.V. and
Leitfaden fĂŒr VereinsgrĂŒnder | akademie.de - Praxiswissen fĂŒr SelbststĂ€ndige

Regarding “liability”: “e.V.” would be the right organizational format as it’s an legal entity on its own.
Regarding “non-profit”: this has to be defined in the charter and needs to be approve by the german tax authority.

So finding 7 people for the foundation of the “e.V.” shouldn’t be a problem? :smile:

I think most of the addons should be broken away from the main code base.

It seems that a Kodi type architecture would be well suited for openhab. Move the addons into their own repositories (perhaps with a few of the core ones remaining in the main repo), and let users add various addon repos to their runtime as they see fit. Some will take the plunge and use unmature addons, and others will stick only with what is stable. Each addon will develop its own quality reputation.

Additionally it would be great if there was a way to write addons in python instead of java. It would make basic development much easier, especially for newcomers.

If these two goals could be achieved it should take a ton of weight off the core developers as far as maintenance is concerned, and it should make addon development quicker and easier. Openhab could start growing much faster


At the same time it will deteriorate the code quality and stop the growing of the openHAB code base as addons will be all over the place, but not part of the project. This is the risk that we have to balance against.

1 Like

As the discussions are now rather mixing different topics here, I would like to close this topic and started 3 separate ones in its place - so feel free to follow up on these: