Add, or enhance existing script, such that there is a query of database rows for a specific org.

Alternatively, show for each org.

queries/db-summary.sh

Either a verbose mode, or a quiet mode depending.

Pass an output stream of some kind down and either default to a null one, or place a null one in when requested.

Need to parse the content out of the README files. There appear to be two ways to indicate the badges:

Examples:

[![Code Climate](https://codeclimate.com/github/aws/aws-codedeploy-agent.png)](https://codeclimate.com/github/aws/aws-codedeploy-agent)

.. image:: https://travis-ci.org/aws/aws-cli.png?branch=develop
   :target: https://travis-ci.org/aws/aws-cli
   :alt: Build Status

Even when an organization has public members, running in public mode isn't picking them up. Need to investigate what the API is sending back.

Has to be downloaded. Need to convert to png.

Similar to the source reports section, make the reports section a pluggable sql-reports API.

Add a GitHub report for outside collaborators across the org.

The report names don't show if the issues aren't downloaded yet.

Add a get started script, or a flag to refresh_dashboard that takes an org and a directory rather than a config file.
It begins by creating that directory, if needed, and generating a standard configuration file for it. A github file is also made and the user instructed to:

a) Updated the github config file with their personal access token.
b) Then run in the normal way.

Alternatively it could wait on user input like a wizard, though I would always leave the personal access token adding to the file to the user.

Currently the issue syncing doesn't pull labels or milestones. Pull those and include in the dashboard.

Using the data-directory, make a db directory, then create a gh-sync.db file and fill with DDL. Remove requirement on a shell script.

Currently the code lets you do everything, run in light mode or run a particular phase. Change it to allow multiple phases to be listed (at which point 'light' is just an alias for an internal list, as is the default being everything).

Currently the source reports are run directly on the checked out code.

Consider moving this to the GitHub search API:

https://developer.github.com/v3/search/

While there might be a reason for the source checkout (for example running existing tooling over the source), the current source reports all look like they can be implemented as search requests.

Downside - yet more running out of rate limited requests.

Add mouseover to the charts so you can see the data points.

Currently it uses git on the command line to pull the source. Need to move to GitHub API, or at least do so for private source if that proves a performance issue. Alternatively, allow a flag that says "I'm logged in, checkout private code".

Either move to, or also support, PostgreSQL.

Do a "All Organizations" dashboard. The XSLT should work for this (with some bugfixing).

I'm getting a dashboard with Team (-1) and broken navigation. I think it's when you start with an org in public mode, then add that you have private access later.

Looks ugly currently; needs a look and feel. Essentials are:

• Font, text size
• Table spacing
• Page margins

Now that the Owners team is frowned upon, there's no reason to keep it filtered out of the dashboard. Remove that logic.

Currently the issues sync by looping over every repository and pulling any changed issues for that repository.

This could be optimized by pulling only the changed issues for an organization.

Show activity over last .

Currently charts are hard coded. The data should be moved out to JSON files rather than inline, and there should be a way to add your own charts.

Add sorting logic to each column of both db and source reports.

I've been adding columns and tables. Need to be more helpful and show what tweaks to do to update a db.

Looks like the Team tab in Team dashboard mode isn't displaying well.

Include the number of requests left more often in the output. Perhaps at the start of every phase.

For example, to show that the requester of an issue was a member of the org.

Need to show these in Members, with something to indicate they're an outside collaborator.

Also show them in Teams.

One may have internal data; for example an internal url for a private wiki page, or the name of the manager owning the software, or an address in the ticketing system.

With the current setup, these could easily go into the db in their own table (as designed by the user), and the db-reporting could pull them out. They wouldn't show on other tabs, so you'd have db reports of Repository Managers, and maybe 'Lacks Repository Manager'. Including these in other tabs would be preferable but would involve having to integrate custom data to those tabs.

On AllOrgs, need to figure out how that would look.

Allow for individual running of a phase?
Have a verbose mode to see each step happening?

Move from positional args to proper -- args.

Keep the config as required.

Not seeing commits in the database. Wonder why?

Currently only the org dashboard is generated. The XSLT should run for the team.

Unlike the source reports (whose context is github files), the db reports aren't typed.

Have an API that gets recorded in the metadata header. It should cover:

• Pretty Name of DB Reporter (Source Reporter need this too)
• Title for each column
• Type of each column so some special logic can be offered. For example, type of 'repository' would get a link to the repo. Same for members etc.

Open question is whether to encourage additional fields. Like a 'send email' link to tell no 2fa folk to turn on 2fa.

https://developer.github.com/v3/repos/statistics/

A lot of data :/

It's in the db, so should use it.

Assuming only one org being shown, use the colours in the avatar to define the theme of the page and the colours in the charting.

This could include: "Make the colours in the charting depend on the bootstrap theme".

Org metadata.

Need somewhere for org metadata to be shown too.

Rather than just a to the file, have a and a .

The members tab shows a member multiple times if they are a member of multiple orgs. Same for the member related reports.

Some mechanism to define a list of repositories to be looked at.

Rather than filtering, having a repositories : [ ] entry in the config may be the simplest. Would be in org/repo format.