oddballteam / magnifier Goto Github PK

Background

This is an epic that will track the work required to add Pull Requests Reviewed. Originally from this conversation

• Add column to statistic for reviewers
  • Identical structure and implementation as the assignees column
• Git hub service endpoint
• Git hub persist class and updateorcreate class to save to the db
  • Exclude the author
• BE graphql
  • Add an ownership type of "reviewer"
    □ StatisticOwnershipEnumType
  • Update the statistics query rb resolver and specs
• Have to query it from the FE
  • Add a Statistics collection in statistics js
  • Graphql Query in statistics queries js
• This new feature will need to be added to the "Week in Review submittal" page and process, as well (this work needs to be broken out into individual tickets)

Background

When the user is ready, they'll need a page to submit their week's accomplishments.

Definition of Done

• 'submit' button from WIR page bringing them into a page to begin the submittal process
• entering the page creates a WeekInReview db record and associated Accomplishment records
• new page displays all of their current stats/accomplishments for the selected week
• all the stats have a 'remove' icon
• clicking remove removes the stat for their week
• page carves out a comments section (to be completed in an upcoming issue)
• page carves out an 'add stat' section (to be completed in an upcoming issue)

Background

In order to pull data from private GitHub repos, we will need to authenticate the given user. This can be done through:

1. a user's personal access token
2. An OAuth access token

We favor option 2.

Definition of done

• Outline the implementation
• Create the atomic GitHub issues that represent what is required to implement this work
• One of the issues should be a spike involving testing an OAuth token on a deployed server (testing locally can return false positives)

Background

In order to pick a front end graqphql client of choice, we need to discuss pros and cons of both

Definition of Done

• Document attached to this ticket, and discussed at next group meeting

Out of the available solutions, research different options and identify a recommended solution for a small project. Both financial and administrative costs are a factor here with a preference for simplicity, very low cost and little ongoing maintenance.

Options:

• Vault
• AWS Parameter Store
• AWS Secret Manager
• Synthetic options like credstash
• JSON in S3

Background

Managers will need to export a given user's week in review. For this first iteration, this will be a CSV file.

Definition of Done

• Ability to export a user's week in review as a CSV file

Background

Authenticated users can access pages, guests cannot.

Definition of Done

• All pages can only be accessed by logged in users
• There is a logout button that logs a user out

Background

Once #81 is completed, we will need the ability for a user to be able to select one or many of these new available stats, and add them to their Week in Review.

Definition of Done

• From the column of available statistics, a user can select one or many statistics to be added to the currently displayed WIR
• Confirm dialogue pops up before they are added
• Once added the stats no longer appear in the "available" column
• Once added the stats appear in their Week in Review

Background

Per human error, someone might mistakenly push changes directly to master.

Definition of Done

• Research and implement a protection that prohibit's user's from accidentally pushing directly to master

Background

We want our FE to be able to make GraphQL queries that satisfy our MVP goal criteria.

Definition of Done

• FE can submit a GraphQL query for each of the below:
  • How many issues did they create?
  • How many issues did they work?
  • How many issues did they close?
  • How many PRs did they create?
  • How many PRs did they work?
  • How many PRs did they close?
  • What are the links to each one of the above?

Background

The vision is to have daily cron jobs that pull data from GitHub and JIRA, and we compile that data into our database smartly. The resulting db tables should align between the two, meet all of the MVP criteria, and be scalable for the Post-MVP goals.

Definition of done

• Research JIRA's API for compatibility and common overlap with GitHub issues
• Propose a database schema
• Build out the initial database design, based on the proposal

Background

We should have some CI/CD tooling in place to run automated tests/linters etc. as well as for ease of deployment.

All the following options have free tiers for open source:

CircleCI
Travis
Semaphore

We could also just use builtin Heroku CI if that's where we're launching

Definition of done

• A successful test deployment
• A successful CI run
• Create documentation for the group capturing the details of the deployment process

Background

We need to determine what our budget and deployment platform will be for this tool.

Heroku is a potential platform that could suit our needs (also includes built-in CI). 1x dyno at $25/mo would be sufficient, as this platform will only be used by Oddballers, and thus will have a limited volume of traffic/resource usage.

The focus should be on simplicity and cost-effectiveness. We don't want to wrestle with too much manual configuration or maintenance if we can avoid it.

cc: @RobAWilkinson

Definition of Done

• Budgetary concerns are addressed and codified
• Deployment platform is decided upon

Background

Rather than deal with the hassles of manually linting, set up prettier w/ eslint and provide instructions on how to autoformat on save.

Include in the same PR running it across all JS files

Definition of Done

• Prettier set up w/ eslint
• Clean report from running eslint

Background

In order for user to gather data from GitHub's API on a given user, we need their GitHub:

• personal access token
• username
• organization where the issues and pull requests reside

Definition of Done

• Profile page with form
• Form to set/update a user's GitHub personal access token, username, and organization

Background

Want to make contributing as accessible as possible. Getting the app up and running locally is a key to this.

Definition of Done

• Adds any necessary instructions, links, details, etc., to get the app up and running

Background

In order to make it easier to have tests running automatically would be nice to have an automatic test runner.

Is guard still the defacto standard?

Definition of Done

• test watcher configured and running, instructions in readme

Background

Need to integrate react router for client side routing

Definition of Done

• React router is in package and configured

Background

Let's use the most current, stable versions of Rails and Ruby.

Definition of done

• Upgrade to Rails 5.2
• Upgrade to Ruby 2.5

Background

There will be times when a user needs to manually add in an issue or pull request into their week in review, that is not showing up already.

Tasks

• GitHub service objects to find an issue/PR based on its HTML URL (#92)
  • one for issues, and one for PRs
• Persist new issue/PR as a Statistic (#94)
  • Must figure out the appropriate attributes (i.e. merged, assignees, etc.)
  • Create associated Organization record if not in our db
    • can be derived from the passed HTML URL
• Service class that takes in a Statistic record and creates the appropriate Accomplishment records for the associated WeekInReview record (#96)
  • Even if the user is not a creator or assignee of the statistic
• BE mutation that takes in the FE mutation request (#98)
  • first checks if the Statistic issue/PR already exists in our db
  • else, fetch from GitHub and persist to db
  • create appropriate Accomplishment records
• When user pastes URL into FE form, it sends mutation to BE to smartly add it to their WeekInReview (#102)
  • create FE mutation request
  • leverage loading from mutation to display something in the UI during processing
  • refetchQueries to update the page with the new Statistic in the appropriate categories
  • SweetAlert showing success/failure

In order to get this working, need to add contributors

Background

Background is the TODO here:

TODO: Maxing the page size at 100 is standing in place for implementing
a pagination solution. At this point, as we will have daily cron jobs
for these endpoints, it is unrealistic to think that any user would have
more than 100 items returned in any of these endpoints, in a given day.
As such, pagination is not yet required.

Definition of Done

• When necessary, implement a pagination solution that leverages GitHub's pagination feedback

Background

Once we have started saving all of the GitHub and JIRA data in our database, we will want to offer up that data to our FE through a GraphQL server.

Here is a graphql-ruby tutorial for reference: https://www.howtographql.com/graphql-ruby/0-introduction/

Definition of done

• An outline of the process
• Create all of the atomic issues (in GitHub) that represent the implementation of the GraphQL server in Ruby

Background

The current logic is excluding closed PRs, and only tracking open and merged PRs. Keifer and I are now thinking that the developer puts in (sometimes significant) time on a PR, and sometimes they do not get merged. The dev should not get penalized for that, as it reflective of work that was done during the course of the week.

Definition of Done

• Includes closed PRs when pulling data from GitHub, and presenting data in our views

Background

We should keep as much information as possible within the built-in Github wiki, so that developers have quicker access to frequented information. Currently we have a large design document living on hack.md.

This information should be parceled and added to the wiki.

Note: remember to add links to new pages into the sidebar so we can edit the order, add nesting as needed, etc. (Builtin "pages" widget is dumb and doesn't support ordering.)

Definition of Done

• All information captured in this document has been migrated to this wiki.

Background

The week in review page, by default, builds the user's current week in review based on the data we get from GitHub's API.

The user needs the ability to remove a given issue or PR, should it be incorrect.

Definition of Done

• Button/icon the user can click on to remove a given issue/PR from the given week's 'week in review'
• confirmation prompt before removing
• confirmation that the issue/pr was removed (and no longer showing on the page, or on refresh)

Background

We've determined that we will deploy to our existing AWS cloud resources. This ticket will track the devops work required to implement this deployment pipeline.

Definition of Done

• Developer can deploy changes to infrastructure and view changes at magnifier.oddball.io
• very user friendly for developers to access: prods rails console, run rake tasks in prod, tail the production logs

Background

In getting started with the base Rails project, add in any best practice gems to enhance developer experience, and code quality.

Definition of done

• Adds and configures testing related gems (e.g. RSpec, FactoryBot)
• Adds and configures code quality gem, namely RuboCop

Background

As a developer, I want to not fuss with development dependencies. I should be able to run the application (with all dependencies) in a docker container. This will also allow us to more easily deploy to AWS via our container registry.

Definition of Done

• Application can be run immediately after clone via docker-compose up command
• Wiki + readme updated with local development instructions

Background

We need to pull in stats on our users on a daily basis. This will be done through a daily cron job that executes this rake task:

https://github.com/oddballio/magnifier/blob/master/lib/tasks/github.rake#L16-L56

Definition of Done

• Sets up a daily cron job to run this rake task

Background

For the current user, the Week In Review page should now display:

• one week’s worth of statistics
• statistics dynamically, meaning it updates itself as the week progress, pulling in any new updates in the database
• the statistics for the selected week only
• the week’s start and end dates, that the statistics fall within
• the associated employee, meaning the current user

It does not create a WeekInReview db record, and the associated Accomplishment db records, as it used to.

This will now happen as part of a workflow where the user decided to “begin the week in review submittal process”, in upcoming stories.

Issue Resolved

Issue #

Definition of Done

• when user visits WIR page, it presents the stats that fall within the week of the selected date
• dynamically updates with stats that are present in the database
• displays the start and end dates of the selected week
• displays the employee (current user)
• displays one week's worth of stats

Background

In order to allow oddballs to login with their email address, need to set up oauth2 with google.

Definition of done

• Backend and front end are configured to allow for oddball to login

Background

We are currently getting back a list of Statistics for a given time period (i.e. this week, last week, etc.), broken out into the 6 MVP categories (i.e. issues created, issues worked, etc.).

We need to be able to persist all of these statistics as a user's "week in review". For this first iteration, we'll work with "this week's" statistics.

Definition of Done

• database tables for persisting the week in review

Background

Set up apollo client and integrate it with react on the front end

Definition of Done

• apollo is working and can query the api

Background

In our daily rake tasks, we will be fetching issue and PR data directly from GitHub's API through our Githhub::Service object calls. This data needs to be persisted to our database in our db tables respectively:

• Statistic
• GithubUser
• Organization
• Repository

Definition of Done

• Logic that takes the responses from our Github::Service calls, and smartly persists them to the approriate db table
• Spec coverage
• Yard docs

Discover and documented a basic understanding of how a logged in user might be able to access tickets within a Jira workspace.

Feel free to create a free account on the Jenkins board in order to play around with things

This ticket is done when we have the ability to create other tickets for the work to be done

Background

We need a rake task that can be called one a day, to get the previous day's worth of GitHub user data. This will fetch all of our user's issues and pull request activity, for the previous day.

Definition of Done

• Rake task that fetches and saves all user's GitHub data for the previous day

Background

We are seeing these security alerts from GitHub, based on our current gem versions:

https://github.com/oddballio/magnifier/network/alerts

Definition of Done

• Update gems per the recommendations
• Ensure passing specs

Background

We should codify and document our workflow steps so everyone is on the same page. There is a WIP wiki page here.

Definition of Done

• Workflow steps are documented in wiki

Background

We are currently getting back a list of Statistics for a given time period (i.e. this week, last week, etc.), broken out into the 6 MVP categories (i.e. issues created, issues worked, etc.).

We need to be able to persist all of these statistics as a user's "week in review".

The required database work was completed in #69

Definition of Done

• a page that defaults to the current user's proposed week in review statistics
• current proposed statistics are saved to the database as their initial week in review

Background

Our goal is to use React as our dedicated FE layer, and to make GraphQL queries from it, to our Ruby GraphQL BE server.

Definition of done

• Adds React and all associated dependencies
• Creates a proof of concept 'Hello world' page to illustrate successful wiring
• Document the process for passing data from Rails to React, and vice versa

Background

In the new Week in Review submittal page, we need the ability to be able to add/update comments to it.

Definition of Done

• Can add any of the four comment types
• If comments are already present, they show up in the correct text area
• If a comment does not exist, we create one
• If a comment does exist and is updated, we update it

Background

When a user visits their WIR page, if the WIR is already built, it returns it, and all of its already associated stats. If the WIR is not yet built, it builds it based of all that stats that are currently in our db (for the week in question).

In the former case, where the WIR already exists, we need a way for a user to see any new stats that have popped up, since their last visit. Here is an example:

• The user logs into their WIR page for the first time this week, on Wednesday
• Since this is their first time visiting the page this week, they do not yet have a WIR
• So we create one for them, with all of their activity from Monday - Wednesday
• Then they do more work during the week
• Then they visit their WIR page again on Friday
• Since they already have a WIR for this week, we return that; however, they have new work since Wednesday
• We want to show them a diff of their new statistics that are:
  • not in their current WIR already
  • have occurred since Wednesday

In a follow up story, we will give the user the ability to select one/many of these "new" stats, and add them to their WIR.

In another follow up story we could also create a "Rebuild your WIR" type button that deletes their current WIR, and rebuilds it based on the current datetime.

Definition of Done

• In the Week in Review page, the right hand column should contain a list of available stats that:
  • are not currently in the selected week's WIR
  • and have occurred since the most recent stat's source_udpated_at timestamp
  • occurred before the end date of the current selected week

Background

The daily cron jobs that will be hitting GitHub's API will largely be hitting their Search Issues endpoint. We will need to create a new service object to support this.

This new service object will replace the GitHub::Service#spike method. We will want it to dynamically accept many query parameter combinations.

Definition of Done

• Replace the GitHub::Service#spike method with a new service object that hits GitHub's Search Issues endpoint
• VCR spec coverage
• Yard docs

Background

In order to allow a user to set their organization, they need to be able to select a real one from the DB

Definition of Done

• a user sees a list of real organization on the front end

Background

In it's current state, running master fails to render the GET / route as there is no template given. This can be fixed by renaming app/views/pages/root.html.erb to app/views/pages/index.html.erb

Definition of Done

• Replace app/views/pages/root.html.erb with app/views/pages/index.html.erb
• Running the application and navigating to http://localhost:3000 renders the Hello component

Background

As a developer I do not want to have extant rubocop violations in the code base.

Fix violations and remove the todo file.

Definition of Done

• All violations in .rubocop_todo.yml are fixed
• .rubocop_todo.yml is removed
• Rubocop passes

Background

We will need to purchase a domain name for the app's deployment.

Definition of Done

• Collaborate with the team on available domain names
• Work with @RobAWilkinson to purchase a domain