Create a dashboard on the website

[KhudaDad414]

Reason/Context

AsyncAPI Initiative has 55 repositories as of writing this issue. It is hard to have a clear picture of what is going on in the initiative and where. the Shape Up was a great attempt to create a clear picture of what is currently happening and what should happen which unfortunately only went on for three cycles. I think a dashboard on the website would be an amazing tool to have.

Why do we need a dashboard?

Well, A dashboard would help new contributors to select and start working on a good-first-issue and will help maintainers to have a clear picture of what is going on in the Initiative.

What are the main features of the dashboard?

We can add more and more features in the future but now we can go with two.

1. A list of Good First Issues that can be filtered by the repo, type and language maybe?
2. A list of currently hot issues in all repositories.

Description

what should be the location of the dashboard on the website?

It can be separate from the website somewhere like dashboard.asyncapi.com or similar.

How is it going to be implemented?

this feature can be implemented in three steps.

1. Collecting data from repositories using Github Actions and Github Graphql APIs.
2. Storing those data in Projects (beta).
3. Redeploy the website on-demand or in time intervals maybe?

Scenario 1

• an issue is tagged as "good-first-issue".
• this would trigger an action that does two things:
  a) add the issue to the projects (beta) list of the Good First Issues.
  b) trigger a deployment of the website with the latest updates.

Scenario 2

• someone comments on an issue.
• this would trigger an action that would do two things:
  a) update the "hotness" of that issue on the projects (beta).
  (I am not sure how we could calculate it though. maybe comments+reactions/unit-of-time?)
  b) trigger a deployment that queries the top hot issues from projects (beta) and updates the website.

[AceTheCreator]

@KhudaDad414 That's a very lovely idea you've got there. IMHO I think this would make it really easy for new contributors to have a quick overview of what repo they can start contributing to, also based on the issue label.

[derberg]

A list of Good First Issues that can be filtered by the repo, type and language maybe?

It is also very important to have information on the difficulty level. Last year I interviewed every single person that contributed to the project through Hacktoberfest and they said that the best stuff was our single list like this where they could not only see what language is involved but also difficulty level.

It can be separate from the website somewhere like dashboard.asyncapi.com or similar.

why do we need a subdomain, why not just asyncapi.com/community ?

Scenario 1

yup, definitely, GH Actions workflow in every repo that reacts on label added event

trigger a deployment of the website with the latest updates

I suggest we don't do it, dashboard will not be visited by 100s of people every day and doesn't have to be refreshed with current state "real-time". Netlify is free but not unlimited, we should always carefully care about the build minutes limits. Better have a cron-job that runs website rebuilt one a day or once a week. Definitely something to consider 🤔

I am not sure how we could calculate it though. maybe comments+reactions/unit-of-time?

I think it is all that you mentioned, we just need to agree on an algorithm. Like if the issue has more than 3 reactions added in a day or more than 3 comments added in a day - or something like that. Then, when you save such a "hot" issue/PR, you save information about amount of reactions and comments, and we use these to sort and pick the hotest.

[KhudaDad414]

@AceTheCreator It was @fmvilas idea, but still, thank you. 😄

[fmvilas]

why do we need a subdomain, why not just asyncapi.com/community ?

Yeah, I think we can have it on the website. No "need" for a separate domain.

I suggest we don't do it, dashboard will not be visited by 100s of people every day and doesn't have to be refreshed with current state "real-time". Netlify is free but not unlimited, we should always carefully care about the build minutes limits. Better have a cron-job that runs website rebuilt one a day or once a week. Definitely something to consider 🤔

That would be sufficient for now, yeah. Maybe once a day and we can increase it if we think we need it. @KhudaDad414 if we end up doing it with this approach, you would not need to store information anywhere. Just a few API calls during the deployment to grab all the good-first-issues, hot issues, etc. No problem with API rate limits as it's only once a day (the website is not deployed so frequently either).

[KhudaDad414]

@KhudaDad414 if we end up doing it with this approach, you would not need to store information anywhere.

this is a great idea. IMO we should introduce extra tags for good-first issues like Lukasz said. e.g. language that is involved and the difficulty level.

[derberg]

Just a few API calls during the deployment to grab all the good-first-issues, hot issues, etc. No problem with API rate limits as it's only once a day (the website is not deployed so frequently either)

I'm always less optimistic here. Highly recommend doing a test from https://docs.github.com/en/graphql/overview/explorer with rate limit check to check a cost of such a call. We are doing a lot of calls to API already on PRs, and different workflows, like checking stale issues or other stuff. I recommend this presentation from Rea where she shares a hidden costs of API calls on GraphQL.

Just saying that eventually your initial idea to react on event and aggregate data is really the best one imho

language that is involved and the difficulty level.

just suggest labels names and colors. We definitely need prefixes for them. So maybe lang/javascript and complex/easy or something like this

[KhudaDad414]

@derberg @fmvilas
experimented with Graphql API and IMO we should go with a hybrid approach. for each feature, we can calculate the cost of the queries. if it's feasible to query at deploy time we can do that and if it is not feasible we can go with the data collection approach. I calculated the cost for the two main features and here is the result:

Good First Issues

to query all of the good first issues along with their labels it will cost 12 points which is not a lot so we can query them at deploy time.

Hot Issues

Since we have to query all of the comments and reactions as well for all issues and PRs, it is simply not possible to query at deploy time. I don't have an exact amount since we have to go FIVE levels deep which would require pagination in multiple levels. but it is definitely in thousands. unless someone comes up with a clever approach, we should go with a data collection approach for this one.

[derberg]

so I guess that to not overcomplicate, we should just do data collection for both really, right?

[KhudaDad414]

Update:

The data collection part is done (maybe). you can play around with it here and see the collected data Here and Here.

An small issue with hot Issues/PRs:

Something that I haven't anticipated is that we can't trigger GitHub Actions by reactions to comments and issues. we are considering each reaction as a point but recalculation of scores is relying on comments being added. ( we can add other actions to trigger the recalculation of scores like, ready for review, labelling etc.)

API call costs

every action costs 2 but recalculation of scores for each issue/PR costs 3.

[derberg]

I see this but no labels here that would indicate code or complexity. I guess I need to look somewhere else, right? or was it manually added?

Nevertheless, it looks neat! For sure we need to clearly document what is the calculation algorithm behind Hot Issues and PRs

Something that I haven't anticipated is that we can't trigger GitHub Actions by reactions to comments and issues

Actually, I think it better if the calculation would not react to the event but on a cron schedule. Like once a day, we do not need real-time data "refreshment" there I think

[KhudaDad414]

I see this but no labels here that would indicate code or complexity. I guess I need to look somewhere else, right? or was it manually added?

I added them manually in this repo.

we need to clearly document what is the calculation algorithm behind Hot Issues and PRs

Well, IMO we can use the Hacker News algorithm (It's simple and sweet 🍬 ).
p / (t + 2)^1.8
p = comments + reactions + reviews ...
t = age of issue (Hacker News puts the hours here, maybe we can go by day?)

I think it better if the calculation would not react to the event but on a cron schedule. Like once a day, we do not need real-time data "refreshment" there I think.

Since we have around 600 issues and PRs open right now, it would cost around 1800 points to refresh the scores at the same hour... which is a lot. I am experimenting with Github search API and I think I can come up with a custom solution to pull everything from Github with less than 200 points. If that was successful, then we can ditch all of the complications and pull everything once a day.

[derberg]

I'm not sure we should take age into account, HackerNews has a different scope, age plays an important role there, but here, where things are always super slow in open source, I think age should probably be ignored. Maybe we need a label that we can set on issue or PR to ignore it for HOT calculation? not sure

[KhudaDad414]

@derberg I see your point there. But if we take out the age factor then "hot" has no meaning here. maybe we can call them "All-time popular open Issues/PR" or something like that. The idea behind hot issues/PRs is that we should be able to see where the community is focused right now or what is "hot" in the whole community. Hacker News posts age every hour, issues can age every day, every week, or maybe every month. we can find a sweet spot. Why not have both though 🤔 ? popular issues (no ageing) and hot issues (ageing)?

[derberg]

you have a valid point mate. Maybe let us have a look at some examples, and the best is asyncapi/spec#618

• do we count age from issue creation or last comment?
• month should be good but only from last comment I think