Skip to content
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

Open
wants to merge 2 commits into
base: website
Choose a base branch
from

Conversation

daschuer
Copy link
Member

@daschuer daschuer commented Nov 10, 2021

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?

@daschuer
Copy link
Member Author

@Swiftb0y
Copy link
Member

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.

@daschuer
Copy link
Member Author

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.

@daschuer
Copy link
Member Author

We need also consider controllers with two topics.

@Swiftb0y
Copy link
Member

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.

@daschuer
Copy link
Member Author

Yes, that sounds reasonable.

Who with staff privileges can help here?

@Holzhaus
Copy link
Member

Holzhaus commented Nov 10, 2021

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:

  1. What controller should I buy when I intend to use Mixxx?
  2. Is the controller I already own supported by Mixxx?
  3. If it isn't supported, where can I get help for mapping it myself?

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.

@daschuer
Copy link
Member Author

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?

@Be-ing
Copy link
Contributor

Be-ing commented Nov 10, 2021

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.

@daschuer
Copy link
Member Author

As I have already outlined it above: We can hide it.
The main purpose is to inform the core team about controller trends.

@Be-ing
Copy link
Contributor

Be-ing commented Nov 10, 2021

Okay then please remove this new page from the navigation menu.

@Holzhaus
Copy link
Member

The main purpose is to inform the core team about controller trends.

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 tools directory that a developer can run locally and prints to the termibal.

The former could be implement using GH Actions, which supports a cronjob-like workflow AFAIK.

@daschuer
Copy link
Member Author

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.
We can decide later If we just post the results on Zulip or give it a home somewhere else.

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:

  • Lets also introduce three tags for the controller mappings category. Something like:
    • Official Mapping
    • Community Mapping
    • No Mapping
  • Add or extend the sticky not to encourage users to create topic for controllers without a mapping to express the demand.

What do you think?

@daschuer
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants