-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
POC for a Controller Hotlist page #261
base: website
Are you sure you want to change the base?
Conversation
At the moment, it just seems like you'd take all the threads from the controller mapping topic and rank them based on their age and number interactions. However, not all topics are concerning specific controllers. How do you plan to filter out those that are not concerning controllers. And you'd also need to filter out the hardware that already has a mapping. |
Yes, I plan to add a manual ignore list for these topics. Later we may consider to decorate all relevant threads with a discourse tag or something. Since this is a static side we can afford some manual tasks for the first evaluation IMHO. |
We need also consider controllers with two topics. |
I feel like the best option would be to just tag all threads that qualify for the hotlist. Then the python script would just need to query all topics that have this tag attached. Discourse even has a feature to tag topics automatically based on words in the post. The duplicate topic issue would also be solved by this allow-list approach. |
Yes, that sounds reasonable. Who with staff privileges can help here? |
Let's first take a step back and talk about the purpose of such a page before we discuss details how to calculate the "heat", etc. As a user, I'd be interested in 3 things:
For 1/2., you can just check the manual or ask on the forums. For 3., we have the wiki, zulip and the forums. I don't really get what purpose the "hotlist" serves, because it includes both supported controllers and unsupported controllers. If it's just for us to know what controllers our users are interested in, I think the website is the wrong place. Also, we already exceed discourse page view limits, let's not add a bunch of additional crawler traffic everytime the website is built. |
The use cases you mentioned are already covered by various links on the website. The main purpose of this list is to inform the core team about controller market trends. This can be used to derive activities like getting in touch with controller manufacturers and back this up with some trust-able data. The original discussed explicit voting system was, considered as not optimal because of the user expectations it may create. From this perspective this can be a hidden page. On the other hand it would be fair that everyone can have a look at the data. I have picked our website as a home, because we have all facilities at a hand to create such a page. In the final solution this cannot be run on every website build. We need an extra trigger to build it on demand. For the normal builds this should use cached data from a controller-hotlist.md file. Not sure if the should be cron job or just a manual action. Compared to crawlers that request all post via the html interface, we just need some metadata via the json API here, that shall be smaller by a magnitude. But if it turns out to be an issue anyway we can consider to introduce some caching that we only need to requests changes since the last run. I am really curious what would is the top rated controller according to the formula. Does this make sense? |
I share @Holzhaus's concern with putting this on the website. I think this would be misleading. I thought we had agreed that the content for the website or wiki would be a short, manually curated list of well supported controllers for different price ranges. |
As I have already outlined it above: We can hide it. |
Okay then please remove this new page from the navigation menu. |
Then it should be either a bot that posts on Zulip or the forums on a regular basis (montly? Quarterly?) , or just a script in the The former could be implement using GH Actions, which supports a cronjob-like workflow AFAIK. |
OK, I think we have got a common idea. For the sake of easy implementation I will prepare a stand alone Python script that calculates the hotlist. Can one of the Discourse Admins create me a API key? I will limit the script to a small number of queries during debugging to not raise our hit count significant. What's next:
What do you think? |
I like to revive this task. Who can provide me an API key, that is a mandatory step, regardless to the question where to put the data. |
This is a prove of concept of a Controller Hotlist generated from user interactions on Discourse.
What do you think about it. The magic formula to create the heat value for a controller is missing. I need a read only API key to continue here.
In addition we need an ignore list to ignore topics not specific for a certain model and a filter that can mark controllers already supported.
My idea is this magic formula:
Consider all data younger than three years.
heat = ("number actions by user per controller" camped to 0 .. 2) * 3 - last action age form user in years.
What do you think?