Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pull Requests #3

Closed
jayvdb opened this issue Aug 12, 2018 · 4 comments
Closed

Pull Requests #3

jayvdb opened this issue Aug 12, 2018 · 4 comments

Comments

@jayvdb
Copy link

jayvdb commented Aug 12, 2018

It seems yoda was built for a lovely world where issues are always created for every chunk of work to be done.

At least the interface always says Issues and never says Pull Requests, and code search suggests that PRs are usually filtered out. If there is a section which handles Pull Requests, it doesnt seem obvious.

Over in the real world .. people do drive-by pull requests without creating an issue first.

It would be nice to be able to switch to Pull Requests for some of the stats views, or a separate view, and ideally be able to filter out Pull Requests which are linked to Issues (which is not always easy to do).

If a org/repo has a policy of creating an issue for every chunk of work, this PR view would be used by managers as an exception report to check for any open PRs which dont yet have issues created, and any closed PRs which have fallen through the cracks and wont appear on the other view.

@jens-markussen
Copy link
Contributor

Sorry for not responding earlier. Somehow E-mail notifications went to my spam folder. Will consider and respond soon.

@jens-markussen
Copy link
Contributor

It is certainly true that Yoda purposely filters out Pull Requests and concerns itself only with "real" issues. Typically, our pull request are "noise" from a stats/tracking perspective, but I can we that it could be usefull - at least for statistical graphs - to enable a selection. Maybe even to the the point of 1) only issues 2) issues AND pull requests, or 3) just pull requests.

@jens-markussen
Copy link
Contributor

I'll take this issue to imply ability of time stat report to also be able to consider pull requests (radio selection) and add enhancement labels with priority medium.

jens-markussen pushed a commit that referenced this issue Jul 10, 2022
jens-markussen pushed a commit that referenced this issue Aug 16, 2022
* #259 attempt to simplify app authentication

* #259 attempt to simplify app authentication #2

* #259 attempt #3

* #259 back to start

* Fixes #260

* #259 initial try

* #259 update

* #259 debug

* #259 fix

* #259 debug

* #259 fix

* #259 debug

* #259 debug

* #259 fix

* #259 fix

* #259 fix

* #259 fix

* #259 fix

* #259 fix

* #259 attempt at fix

* #259 attempt at fix

* #259 attempt at fix

* #259

* #259 refined alg for finding owner from search term

* #259 fix

* #259 #260

* #260

* #259 #260

* #261

* #261

* #259 keeping things clean. Concerns raised in #261 will be done separately. Have reverted (commented out) working code using ThrottledPromise instaed of Promise
@jens-markussen
Copy link
Contributor

Thinking that maybe it is time to reopen this discussion. There are however, multiple things to consider, including:

  • issue / PR linking. How to represent
  • PR's seldom have many labels (even if they could).. This would render graphs rather uninteresting (volume/timing mostly).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants