Submit this project to Feedmereadmes?

[lasomethingsomething]

Hello: If you'd like a README edit, please let me know and I'll add it to my project backlog. :)

[hyandell]

Cool project (feedmereadmes). First step is probably to look at the maturity model and compare to the readme here, then try and improve. Even a quick glance suggests lots of things missing from this readme.

[lasomethingsomething]

Hi @hyandell: Happy Sunday. Taking a look at the dashboard to edit, and before I begin that part of the process I have to ask you some high-level questions (the answers will form the basis of the intro paragraph):

• what does this dashboard allow people to do/measure? A quick, comprehensive list of its metrics and features would be very helpful.
• Who is currently using the dashboard? Amazon and ... ?
• What makes this dashboard especially great/useful? Is it more: comprehensive/streamlined/straightfoward/other, than existing solutions?
• Why dependent on Postgres? (I can think of good reasons, but would rather put them in your language.)
• What are its limitations? (for example, I see it only pulls in repos from orgs; any other essential parameters users should know?)
• Is there a roadmap that you can insert for potential contributors? The issues tracker has lots of enhacement-tagged items; which of those would you like to prioritize? 3-5 could form a "to-do list."
• I'd pull out some of the detailed contents into sub-pages linked-to from the README to shorten it and make it simpler to follow.

LMK if you'd like to share this info via a different format, like Google Docs. Will send along my email address.

[MaineC]

for example, I see it only pulls in repos from orgs

You can pull repos from users. (See "logins" section in the README)

[hyandell]

Noting that I'm still very much planning to work on this. It's top of my good-intention todo list (ie: things i want to do, rather than things i need to do).

[lasomethingsomething]

No problem, @hyandell. (Note: If you're going to OSSummit Prague or DockerCon EU, we could catch up in person.)

[hyandell]

Starting to refactor the documentation into multiple files:

https://github.com/amzn/oss-dashboard/tree/master/docs

[lasomethingsomething]

Great, @hyandell. Give a shout if you get stuck. :)

[hyandell]

New docs finished and put into place :)

[hyandell]

Reviewing the high level questions (and as not all are covered in the current docs will then ponder how to add that dat):

What does this dashboard allow people to do/measure? A quick, comprehensive list of its metrics and features would be very helpful.

Good question; definitely a miss on the docs atm. The content is there, but I haven't answered it from that perspective.

Who is currently using the dashboard? Amazon and ... ?

No idea :) It's typically an internal product so all I would know is who has mentioned using it historically, or has opened issues/pull-requests.

What makes this dashboard especially great/useful? Is it more: comprehensive/streamlined/straightfoward/other, than existing solutions?

My intent is that it's simpler. That may just mean it's old tech :)

The dashboard-in-a-single-file means that you can run it on an org, then send that in an email to someone. That may go away though as some of these HTML files are getting big.

Why dependent on Postgres? (I can think of good reasons, but would rather put them in your language.)

Two questions here. Why a relational database, and why Postgres.

• Why a relational database? ** I wanted to optimize for easy reporting. SQL queries are a well known technology. Currently they have to be dropped into a Ruby file, but you could imagine having users create only the SQL queries via a UI.
• Why PostgeSQL? ** It's vendor neutral, license happy, feature full relational database. I can also let AWS RDS handle the running of the database for me.

What are its limitations? (for example, I see it only pulls in repos from orgs; any other essential parameters users should know?)

Good question. Thinking out loud:

• Each dashboard it generates goes into a single HTML file. This file can get large; for example my current everything-together dashboard is a 30M HTML file.
• Much of the data is queue-based and scales well, however the metadata has to be loaded in one go. If your metadata load is > 5000 tokens, you'll have issues. I've not hit that yet.
• The output of source reports is not stored in the database.

Is there a roadmap that you can insert for potential contributors? The issues tracker has lots of enhacement-tagged items; which of those would you like to prioritize? 3-5 could form a "to-do list."

I've added a high level direction, more architectural direction than a short list of small items.

I'd pull out some of the detailed contents into sub-pages linked-to from the README to shorten it and make it simpler to follow.

Done.

[jamesiri]

142