search

openhab / website

This repository contains the final artifacts from which the project website is served.
https://www.openhab.org/
20 stars 47 forks source link

Most wanted / upcoming features and bugfixes #12

Open pfink opened 6 years ago

pfink commented 6 years ago

In the community, we repeatedly discussed the concept of a "roadmap" (e.g. here). Many people would like to see an overview of "most wanted" featured and also about upcoming features for the next version. I want to clearly state that, of course, nobody can enforce or guarantee any progress on certain issues within a specified time (so please, let's exclude this discussion here).

But it clearly would help to bring focus on topics that many people are interested in. An issue that already interests many people, will likely also be a point of interest for others who didn't saw the issue yet. The average user is not expert of the openHAB architecture, so he don't know which repositories exist, where too look, how to filter, and so on. For those people (and I'm sure also for technical users) it would be cool to have two dynamic inline overviews on the website:

Most wanted features

Query for all open issues and PRs, descending by +1 reactions / upvotes:

Both queries could be aggregated / merged using the search api.

Upcoming features

Here we would have merged PRs since the last release, preferably also ordered descending by +1 reactions. For filtering the right PRs, probably the same criteria can be used like for @BClark09's changelog: https://gist.github.com/BClark09/6f13345f0a7f38482b444b47c397a1b4

Voting: Currently, the built-in GitHub vote mechanisms are not used so often, and they're also not used consistently. It would be good to give hands-on advice on the website how to vote for an issue or (even better) use some GitHub integration / API to make it possible directly voting for an issue / PR on the website.

kaikreuzer commented 6 years ago

Voting sounds rather awful to me as it implicitly suggests to people that this will influence any priority list of "someone" who implements the stuff for them. Instead of promoting such a passive attitude, we should imho rather show a list of issues labeled as good first issue to help people find a way to join the active development of the project, possibly on the page https://website.openhab.org/about/contributing.html#contribute-code.

Wrt the release notes / upcoming features: I think this is something we should look at in the context of doing regular milestones - yes, they should be listed somewhere, including their generated release notes. With that, even before a release, people will see what is (definitely) going to be in the next release.

Wrt a roadmap, at ESH we trying to keep a rough backlog of things that are considered to be important to work on next. But not all of that might be relevant to openHAB or to end users, so I wouldn't plainly show this anywhere on the openHAB website.

pfink commented 6 years ago

Voting sounds rather awful to me as it implicitly suggests to people that this will influence any priority list of "someone" who implements the stuff for them.

I don't think that such thing is suggested. Anyhow, the priority is actually increasing. How? Swarm intelligence. The higher an issue is voted, the better is the visibility of this issue. The better the visibility, the higher the number of people who are aware of this issue. The higher the number of people aware of a certain issue, the more likely it is that one or more of these people will work on it. An issue that was never seen by any developer at all, has a chance of 0% of making progress. By upvoting, this can be changed.

Of course it should be clearly stated that issues are not resolving from it's own and people should be encouraged to not only vote, but also to work on those issues whenever possible.

Instead of promoting such a passive attitude

Do you really think providing an overview of most wanted features would actually reduce the overall contribution activity? I don't think so.

we should imho rather show a list of issues labeled as good first issue to help people find a way to join the active development of the project, possibly on the page https://website.openhab.org/about/contributing.html#contribute-code.

I don't think that it works this way. People mostly want to work on things they're personally interested in and not something that was "randomly" picked by a maintainer. Issues that already attracted many people, will also more likely be attractive for a developer. Maybe a "good first issue" can help a new developer to make some exercise before starting with the topics he is really interested in, but it won't motivate starting to develop at all.

But not all of that might be relevant to openHAB or to end users, so I wouldn't plainly show this anywhere on the openHAB website.

An issue that is not relevant to any end user very likely won't have enough votes to show up on the website.

ghys commented 6 years ago

Please be advised there is a harsh rate limit on the GitHub API for unauthenticated requests (according to https://developer.github.com/v3/#rate-limiting, 60 requests/hr). After a few calls in several seconds, it will refuse further queries.

To surface popular feature requests, Discourse has a voting plugin, perhaps it would help keeping the end user feature requests out of GitHub issues and avoid them being submitted to the wrong repo. (FWIW, Home Assistant has a feature requests category with voting activated on their forum.)

pfink commented 6 years ago

The website could just cache the result, it does not have to make an API request for every page view, does it?

ghys commented 6 years ago

It's a bunch of static pages generated on each deployment with no server-side, so unless it's cached in the browser's local storage (which has other problems), not really.

pfink commented 6 years ago

But couldn't we easily add a server-side, e.g. a cronjob that updates the static page hourly?

kaikreuzer commented 6 years ago

(FWIW, Home Assistant has a feature requests category with voting activated on their forum.)

That sounds like a pretty good option to me, too!

pfink commented 6 years ago

You mean carving out the feature requests from GitHub issues and migrating them to discourse? Mhm, I'm not convinced...

ThomDietrich commented 6 years ago

I like the general idea here and the suggestion of a discourse category.

@pfink GitHub feature requests are imho a totally different area. All GitHub activity should ideally be reserved for developers. Users most often don't contribute meaningful issues. A Forum category would offer the opportunity for end users to explain their request in a user-perspective. Perfect fit for what you asked for.

Short: I'd love to see this as a vote-based category in the forum.

Confectrician commented 6 years ago

+1 for a vote based discourse solution too. I have mixed feelings about feature requests in a GitHub tool called "issues" for a longer time.

A bit Offtopic: Nevertheless i like the idea of providing some GitHub-Contents/Stats on the website. I had a similar idea about showing our repo maintainers based on the organisation team-members somehow.

The API has a request Limit of 5000 at the moment you authenticate on some way, which should be possible during a cronjob or ci job that starts a script for updating the wanted values.

kaikreuzer commented 6 years ago

I had a similar idea about showing our repo maintainers based on the organisation team-members somehow.

That's not the topic of this issue, but I was thinking of such a page myself for a long time - to easily show, who are the maintainers of which repo and make it more personal by not only listing github handles, but also showing their profile pictures from Github on a nicely rendered page. To avoid github rate limits, it should be ok to pre-generated this info in our groovy scripts that also assemble all the add-on infos.

Confectrician commented 6 years ago

To stop the off-topic: I am already playing around a bit with the api and will open a topic related issue here or in the docs folder, when there's something to discuss. And now back to the original topic and sorry for disturbing here. :hushed:

pfink commented 6 years ago

GitHub feature requests are imho a totally different area. All GitHub activity should ideally be reserved for developers. Users most often don't contribute meaningful issues. A Forum category would offer the opportunity for end users to explain their request in a user-perspective. Perfect fit for what you asked for.

I see it a bit different. I wanted to have an easy-accessible ranking for all concrete issues & feature requests, not for "not meaningful requests / issues explained from a user perspective". I think for those requests it already works right now, the forum offers in fact right now the possibility for users to explain their requests from a user perspective. Other (maybe more expierienced) users can support and eventually point out whether a GitHub issue is the right way to proceed. If it makes sense to add another forum category to handle this stuff, cool, then we should do it. But for me this has nothing to do with the original topic.

So I agree, not every user is able to directly raise a GitHub issue / feature request. But the conclusion for me is not to build up a "parallel world" of ranked issues and feature requests in the forum. The users can of course raise requests & ideas in the forum, but as soon it turns out that there it is a concrete feature request or bug report, IMHO the user should be pointed to GitHub.

ThomDietrich commented 6 years ago

Interesting that we seemingly have the same goal but completely different opinions on the solution. I can only repeat my arguments:

If the goal is to create a place for non-tech-savvy end users to discuss broad ideas and wishes (e.g. "Provide an alternative icon set" or "Offer a setup routine for platform X") they should be able to discuss it freely, discuss it openly with other end users, and should not have to bother with questions like which repo the issue belongs to or which technical questions need to be answered. The new category would not be a "parallel world" but rather an area of the community dedicated to non-technical proposals, ideas and wishes.

gitMiguel commented 4 years ago

(FWIW, Home Assistant has a feature requests category with voting activated on their forum.)

That sounds like a pretty good option to me, too!

@kaikreuzer Is it possible to open this kind of voting category? Especially now as OH v.3 is coming.