chrisglein / react-native-github-dashboard Goto Github PK

Scenarios:

• See all PRs across all the selected repos (filter by issue type)
• See all my issues across all repos (filter by assignee)

When browsing from the website (https://chrisglein.github.io/github-dashboard/) there should be a link back to the repo so it's clear where to file feedback.

• Turn off labels on issues
• Turn off counts on filters
• Turn off sorting by count on filters (show alphabetically)
• Turn off grouping by assignee

http://facebook.github.io/react-native/docs/activityindicator

May be some instructions available here and here

• https://partner.microsoft.com/en-us/dashboard/windows/overview

Running this query makes it look like there aren't many PRs, because the unassigned ones are collapsed. Given that the core scenario for this is to jump on unhandled PRs, this should start unexpanded.

Assigned pull requests show up in the query, which may or may not be desirable depending on the usage

Example: "API: Completion" or "Platform: Desktop"

https://github.com/microsoft/react-native-windows/wiki/Triage-Process

Goal is that someone can go to a url and just use this without having to run it locally.

Alternatively, collapse label groups that only have 1 label in them
Example: "API: Completion" or "Platform: Desktop"

In order to achieve one of the core scenarios #70, there needs to be a query argument for filtering to a label (e.g. "needs triage"). That way you could have one url that shows all "needs triage" across multiple repos, which isn't today possible in the core GitHub UI.

Example:
https://chrisglein.github.io/github-dashboard/?label=bug
https://chrisglein.github.io/github-dashboard/?label%3A"Needs%3A+Triage+%3Amag%3A"

PRs in a draft state should be identifiable from non-draft PRs

One of the usage scenarios for this app is for me to run a query over multiple repos and then mail individuals with their assigned issues and PRs. As a reminder, to spark conversation, etc.

Today I achieve that by running the web mode of the app and copying/pasting the text+links from the web page. The result is something pretty poorly formatted. Better would be something that opens up an email and puts something well formatted in there.

Related #69

For the scenarios we only need the last update and the current one. We should clear that out.

Now there's a store version (#51)... but the query results aren't populating. This is a difference in release builds.

Not sure if it's related, but I see this exception in the debugger:

>	Microsoft.ReactNative.dll!facebook::react::JSIExecutor::callFunction(const std::string & moduleId, const std::string & methodId, const folly::dynamic & arguments) Line 254	C++

+		this	0x000002664fa60470 {runtime_=shared_ptr {...} [2 strong refs] [custom deleter] delegate_=shared_ptr {m_registry=shared_ptr {modules_={ size=14 } modulesByName_={ size=14 } unknownModules_={ size=12 } ...} [5 strong refs] [{_Storage={_Value={modules_={ size=14 } modulesByName_={ size=14 } unknownModules_={ size=12 } ...} } }] ...} [2 strong refs, 1 weak ref] [{_Storage={_Value={m_registry=shared_ptr {modules_={ size=14 } modulesByName_={ size=14 } unknownModules_={ size=12 } ...} [5 strong refs] [{_Storage={_Value={modules_={ size=14 } modulesByName_={ size=14 } unknownModules_={ size=12 } ...} } }] ...} } }] ...}	facebook::react::JSIExecutor *
+		arguments	ARRAY (1), { size=3 }	const folly::dynamic &
+		errorProducer	{moduleId="RCTEventEmitter" methodId="receiveTouches" arguments=ARRAY (1), { size=3 } }	facebook::react::JSIExecutor::callFunction::__l2::<lambda_5fa7bcfa05425a85abfc000aad7694f5>
+		methodId	"receiveTouches"	const std::string &
+		moduleId	"RCTEventEmitter"	const std::string &
+		ret	{kind_=UndefinedKind (0) data_={boolean=true (2) number=9.881312916825e-324#DEN pointer={ptr_=0x0000000000000002 {...} } } }	facebook::jsi::Value
+		s	{m_section={args_={ size=8 } tag_=1024 id_=877 ...} }	facebook::react::ConcreteSystraceSection

An issue with RCTEventEmitter and receiveTouches in Release builds is also reported here, although I'm not using the video module (only async-storage).

Currently it always loads the cached version regardless of how old. Good for development (github API throttling), bad for actual experience.

Or could just group them, similar to issues grouped by milestone.

Part of the whole point of this tool is to combine multiple repos. But sometimes you want to drill in. And often you want to at a glance see what repo each issue came from.

Would be nice to:

• Source repo shows like a label on each repo
• Have nicknames for each repo (instead of full names)
• Be able to have one repo be "default" (empty nickname?)
• Be able to filter per-repo

RN 0.66 has been released. The RNW 0.66 preview will happen shortly.
The app is currently on version 0.63, so really any progress here to 0.64 or 0.65 is welcome.

Follow instructions here from the RNW docs.

These are the core scenarios I think this tool can be used for:

Triage

• Url includes "needs triage" and "needs attention" labels #88
• Ability to open links in other tabs in bulk

PR monitoring

• Use "issueType=pull_request" url
• Stop collapsing unassigned
• Ability to at a glance see what has a review and what doesn't
• Easy to see age of PR

Weekly summary mail

• Easy export directly to mailto (either good copy/paste, or a mail button) #8
• Highlight what's new/gone over a week's timespan
• Mapping of github name to alias (nice to have)

Personal dashboard

• See your assigned issues/PRs (use "assignee=" url)
• See what is new in some timespan (within the last week/day/visit) #23
• See what disappeared in some timespan (could be closed or moved away)

Error looks something like this (with IP address):

{"message":"API rate limit exceeded for XX.XX.XX.XX. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)","documentation_url":"https://developer.github.com/v3/#rate-limiting"}

As is it'll fail without showing that this is why it failed, and also keep trying.

The idea here would be that you could check your page daily/weekly/monthly (whatever cadence) and get a clean view of what new items you have, and what items you used to have.

Currently the app takes data off of github and saves it into a cache. To implement this feature that cache would need to be dated (I took some steps on that) and the query code would need to load in both the most recent data and the second most recent data. With having both sets loaded, it would then identify what id'd items were in one set but not the other set. That gives you what is new (wasn't in old set) and what is resolved/moved (isn't in new set). Then those items can be tagged in the data the UI consumes, and then given a different visual treatment.