I renamed repo_owner to username, so the terminology would fit these changes. This is a breaking change!

Also, I made it so that the tool looks for an organization if repo_name is left empty. Unfortunately, users may have to read the docs to understand this. Feel free to make suggestions or contributions for this.

I have updated the docs to reflect these changes.

Closes #14

It would be nice if there were an option for part of the points to be awarded as the card starts moving through the project board.

Some sensible defaults would be to award 50% of the points when a task moves to "In Progress" and 75% of the points when the task is "In Review", however this should be customizable in the per-project settings. There will also need to be a way for users to specify which columns are "In Progress" or "In Review", again per project.

Other considerations:

• If a task goes back to "In Progress" after a review requested changes, then the point award for "In Review" should still stay as long as the task was in that column, but as soon as the task goes back to "In Progress" the point award will drop until the task is again "In Review"
  • This could be implemented within the card using a points_completed_as_of(date) function.

This project was processing dates without proper consideration of their timezones. As such, several bizarre errors errors were happening, especially around the start and end of a sprint.

For example, issues closed at 6pm Arizona time on the last day of the sprint were not having their points credited to that day on the burndown chart because GitHub returned that closed date as 1am UTC the following day.

This project now processes all dates internally using UTC. The sprint_start_date and sprint_end_date are assumed to be at 00:00:00 local time, and the final burndown chart is rendered in local time.

These changes fix #17 and fix #21

GitHub stores issue create/close dates in UTC, but this project often uses the local time of the user running it. Ignoring timezone info, this often means that the GitHub create/close dates appear in the future, which can cause problems like the one reported in #17 or this one where closed issues weren't getting counted in point totals because their UTC time make it look like they closed the day after.

Handling of time needs to work better to cover these edge cases.

I am often working on tasks for or overseeing multiple different projects. I'd like to have a way to save all of the configurations for each project and easily switch between them without having to change out the config.json file each time I want to look at a different project's burndown chart.

The program simply crashes when the closedDate of an issue card falls before the sprint_start_date or after the sprint_end_date from the config.

There needs to be a guard to make sure the closedDate is within the bounds of the sprint before attempting to mark its points for a specific day.

The repo that I'm using this for does not have point values assigned to its issues, which renders the tool unusable. I would like to add support for this. I propose one of the following solutions:

1. Issues without point labels have a default point value of 1
2. If points_label in the config is blank, points are not parsed, and the chart is updated to use the term, "issues" instead of "points"
3. Add some other value to the config that determines whether issues or points are measured

Any feedback would be appreciated.

A task created to make the demo burndown chart look more realistic.

This particular task illustrates the ability to sum up points from multiple points labels.

I am having the following exception when using this application with a private organization:

Traceback (most recent call last):
  File "main.py", line 58, in <module>
    project = download_project_data(args)
  File "main.py", line 29, in download_project_data
    project: Project = get_organization_project()
  File "/Code/github-projects-burndown-chart/src/github_projects_burndown_chart/gh/api_wrapper.py", line 32, in get_organization_project
    return Project(project_data)
  File "/Code/github-projects-burndown-chart/src/github_projects_burndown_chart/gh/project.py", line 9, in __init__
    self.name = project_data['name']
TypeError: 'NoneType' object is not subscriptable

Any idea on what might be going wrong?

Upon some investigation I discovered that the culprit seems to be this request to the GitHub GraphQL API (organization name redacted):

{
   "query":"query OrganizationProject($organization_name: String!, $project_number: Int!, $column_count: Int!, $max_cards_per_column_count: Int!, $labels_per_issue_count: Int!) {\n  organization(login: $organization_name) {\n    project(number: $project_number) {\n      name\n      columns(first: $column_count) {\n        nodes {\n          name\n          cards(first: $max_cards_per_column_count) {\n            nodes {\n              id\n              note\n              state\n              content {\n                ... on Issue {\n                  title\n                  timelineItems(first: 20, itemTypes: [ASSIGNED_EVENT]) {\n                    nodes {\n                      __typename\n                      ... on AssignedEvent {\n                        createdAt\n                      }\n                    }\n                  }\n                  createdAt\n                  closedAt\n                  labels(first: $labels_per_issue_count) {\n                    nodes {\n                      name\n                    }\n                  }\n                }\n              }\n            }\n          }\n        }\n      }\n    }\n  }\n}",
   "variables":{
      "organization_name":"<my org name>",
      "project_number":1,
      "column_count":5,
      "max_cards_per_column_count":50,
      "labels_per_issue_count":5
   }
}

Which is returning the following (request-id redacted):

Headers:

{
   "Server":"GitHub.com",
   "Date":"Fri, 11 Nov 2022 10:54:30 GMT",
   "Content-Type":"application/json; charset=utf-8",
   "Transfer-Encoding":"chunked",
   "X-OAuth-Scopes":"admin:org, project, repo",
   "X-Accepted-OAuth-Scopes":"repo",
   "github-authentication-token-expiration":"2023-02-05 10:43:50 UTC",
   "X-GitHub-Media-Type":"github.v4; format=json",
   "X-RateLimit-Limit":"5000",
   "X-RateLimit-Remaining":"4994",
   "X-RateLimit-Reset":"1668167670",
   "X-RateLimit-Used":"6",
   "X-RateLimit-Resource":"graphql",
   "Access-Control-Expose-Headers":"ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset",
   "Access-Control-Allow-Origin":"*",
   "Strict-Transport-Security":"max-age=31536000; includeSubdomains; preload",
   "X-Frame-Options":"deny",
   "X-Content-Type-Options":"nosniff",
   "X-XSS-Protection":"0",
   "Referrer-Policy":"origin-when-cross-origin, strict-origin-when-cross-origin",
   "Content-Security-Policy":"default-src 'none'",
   "Vary":"Accept-Encoding, Accept, X-Requested-With",
   "Content-Encoding":"gzip",
   "X-GitHub-Request-Id":"<some id>"
}

Content:

b'{"data":{"organization":{"project":null}}}'

It would be really nice to have a chart that showed the relative amount of work put in by each contributor over the course of a sprint. This feature can start with a simple chart showing total points completed per contributor (the blue line), and future versions can support showing additional bars (stacked even?) for different types of tasks.

It would also be great to support splitting points between multiple people who contributed to a single task, but that doesn't have to come immediately.

I just tried to pull a burndown chart for one of my active projects and got a flat line at 0, but no errors. By debugging the code I realized that my points_label setting was wrong (case sensitive issue - potentially another issue) so none of the point values were getting read.

Better checks here would make for a better user experience.