-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Generate a weekly report of activity #24672
Comments
This would run as github action. It might make sense to store historical data somewhere. Or just have a way to piggy back on the last closed issue to get the prior numbers. |
Additional information to report: the unmaintained components and deprecated components. |
Is anyone working on this? Happy to take this on if not |
Go for it @kevinslin :) |
On it :) Any preferred output? (eg. email, csv, markdown table added to the repo) |
The description of the issue says "open an issue for review" - however you want to present the info in the issue is up to you. |
Got an initial version of the OTEL weekly report going. Currently the implementation is a single yaml file which uses https://github.com/actions/github-script Note that the following information is currently missing as I wanted to check in before implementing:
Questions:
1. Delta For Last WeekSome ways of getting the delta:
Recommendations: Non-fragile and side effect free. - add a `JSON Data` section to each issue that has data in json format
- in gh action, fetch previous week issue
- optional but recommended: weekly report issues should have the custom label `report` to filter down results
- use regex to find and parse the json data
- calculate deltas Example of JSON Payload at the bottom of the issue
2. maintained components and deprecated componentsFor format, I was thinking of the following :
In terms of implementation, the plan is to crawl the repo and get status via
Questions:
|
Is the data for this not already available in devstats? Curious if there's way we can leverage what's already there https://opentelemetry.devstats.cncf.io/dashboards |
@codeboten the raw data for devstats is stored in a postgres database and queried via grafana: https://github.com/cncf/devstats-helm#architecture since they store everything from gh-archive, i assume that the data is there somewhere in the postgres. |
Would it not be possible to produce a dashboard there that could include the same information? Not sure what the process to do that is, but it would be super useful to have that information there |
This is not a matter of data or access to data, it's a matter of process. My idea of this report is that we generate it every week, make comments on the issue to resolve or acknowledge the state of the project, and close it. This helps us reduce the overhead of having some of those conversations. |
@atoulme I see the benefit around reducing the overhead to bringing this information to light. I guess I was thinking about this in aggregate, where we could see the overall trend in the project health if we had access to the data over a longer period of time, which seemed like it would be more easily done in a dashboard like devstats. Was an alternative to use a project to facilitate the discussions investigated? |
one other issue with using devstats is that we are also generating business specific stats based on |
I know nothing of those dashboards. I wasn't aware of the grafana instance before you mentioned it today :| It never came up in SIG meetings AFAICT. I don't know how to manage it and I'm just interested in getting topical information in a timely manner with a bias for action through an issue. I'm not sure how we'd use a project to get the same info. Upon digging a bit, there are no dashboards related to labels. The reason is because of the decoupling to labels in a separate table: I can create a chart of occurrences of the event but in effect it tells me little. Maybe there's a better way to go about it, here is a chart of occurrences of the "needs triage" label: Pictures of the chart this year and last 7 days: If we can instead have a cumulative count or keep track of it in some way, that'd work ok. I otherwise am lazy and like the directness of getting an issue with the info I need to query for on the morning of the SIG meeting. |
submitted pr > #26111 |
the report for this week > kevinslin#19 |
Kevin, can you change the style of the list to use Github markdown such as lists show as checklists? |
updated issue format with gh style checkboxes: kevinslin#21 |
report for this week > kevinslin#22 |
PR has been reviewed and approved. ready to merge :) report for this week > kevinslin#25 |
**Description:** This PR creates a gh action that generates a weekly report on repo statistics. It delivers on the requirements specified in #24672 You can see the sample output here: kevinslin#16 **Link to tracking Issue:** #24672 **Testing:** Manual testing in fork: https://github.com/kevinslin/opentelemetry-collector-contrib/actions Example output: kevinslin#17 **Documentation:** The architecture: - we use `actions/github-script@v6` to make calls to the gh apis - we require installing `js-yaml` in order to parse `metadata.yaml` files in order to get components. this dependency is installed during the github action run and not persisted Some caveats about the logic: - when this action runs, it looks back the previous 7 days and gets issues created in that time period, normalizing times to UTC - eg. if running this on wednesday (eg. 2023-08-25 17:35:00), it will scan issues from the previous wednesday (2023-08-18 00:00:00Z) to beginning of this wednesday (2023-08-28 0:00:00Z) - this action writes the json payload of the report inside the issue. the payload is parsed by future reports to calculate deltas - the report issue has a custom label: `report` - this is used so we can properly filter previous issues when calculating deltas. the [github issues api](https://docs.github.com/en/rest/issues/issues?apiVersion=2022-11-28#list-repository-issues) only does filtering based on labels and `since` date This action currently runs every Tuesday at 1AM UTC --------- Co-authored-by: Antoine Toulme <antoine@toulme.name> Co-authored-by: Tyler Helmuth <12352919+TylerHelmuth@users.noreply.github.com>
**Description:** This PR creates a gh action that generates a weekly report on repo statistics. It delivers on the requirements specified in open-telemetry#24672 You can see the sample output here: kevinslin#16 **Link to tracking Issue:** open-telemetry#24672 **Testing:** Manual testing in fork: https://github.com/kevinslin/opentelemetry-collector-contrib/actions Example output: kevinslin#17 **Documentation:** The architecture: - we use `actions/github-script@v6` to make calls to the gh apis - we require installing `js-yaml` in order to parse `metadata.yaml` files in order to get components. this dependency is installed during the github action run and not persisted Some caveats about the logic: - when this action runs, it looks back the previous 7 days and gets issues created in that time period, normalizing times to UTC - eg. if running this on wednesday (eg. 2023-08-25 17:35:00), it will scan issues from the previous wednesday (2023-08-18 00:00:00Z) to beginning of this wednesday (2023-08-28 0:00:00Z) - this action writes the json payload of the report inside the issue. the payload is parsed by future reports to calculate deltas - the report issue has a custom label: `report` - this is used so we can properly filter previous issues when calculating deltas. the [github issues api](https://docs.github.com/en/rest/issues/issues?apiVersion=2022-11-28#list-repository-issues) only does filtering based on labels and `since` date This action currently runs every Tuesday at 1AM UTC --------- Co-authored-by: Antoine Toulme <antoine@toulme.name> Co-authored-by: Tyler Helmuth <12352919+TylerHelmuth@users.noreply.github.com>
This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping |
I'd love to automate some of the begrudging work of looking after the project.
We use this issue as a report during the SIG call, and close it in the call.
The text was updated successfully, but these errors were encountered: