Comments (6)
@konradmayer Wow - thank you so much! I love this idea. I had actually worried a bit that the taskboard_helpers
weren't necessarily a particularly good fit for real-world workflows. Now that you mention tracking the commits, this seems like such a clear winner for an option! I also really appreciate the code example. The illustration really helps.
On the implementation side, I'm torn between two instincts. I love the clean syntax of has_n_commits( count = 1)
since it's very literate and most in line with the other taskboard_helpers
. However, I also want users to do as little work as possible, and I hate to require them to join their own data. Admittedly, I don't have a particularly good reason for this.
The only alternative I can think of is using the syntax has_n_commits( count = 1, events )
and relying on the user to provide the events dataframe (or list) as a prerequisite. Similar to your get_n_commit
function, perhaps this means adding a get_issue_set_events(ref, issues)
function which could either take the output of get_issues
, the output of parse_issues
or a vector of issue numbers and return all the events for that set of issues (iterating over get_issue_events()
as you did.) That sort of function might be of general use, anyway, since the GitHub API unfortunately doesn't allow for any query parameters on Issue Events.
So, in summary, I guess the two potential workflows could be:
my_issues <- get_issues(my_repo, state = "all", since = "2019-01-01") %>% parse_issues()
my_issues_events <- get_issues_set_events(my_repo, my_issues)
viz_taskboard(my_issues, has_n_commits(3, my_issues_events))
or
my_issues <- get_issues(my_repo, state = "all", since = "2019-01-01") %>% parse_issues()
issues <- issues %>% mutate(n_commits = get_n_commits(my_repo, number))
viz_taskboard(my_issues, has_n_commits(3))
Do you have any opinion on which seems more appealing / usable?
Thank you again so much for this great idea!
from projmgr.
FWIW I discovered a quirk with the event data that I'll stash here for future reference. Commit IDs that close issues show up both in a "commit" event and a "closed" event. For exact counts, we may have to do a distinct count or filter non-null commit IDs to "referenced" events only:
library(projmgr)
library(dplyr)
projmgr <- create_repo_ref('emilyriederer', 'projmgr')
#> Requests will authenticate with GITHUB_PAT
issue_events <- get_issue_events(projmgr, 9)
sum( vapply( issue_events, function(x) !is.null( x[["commit_id"]] ) , logical(1) ) )
#> [1] 3
sum( vapply( issue_events, function(x) x[["event"]] == "referenced" , logical(1) ) )
#> [1] 2
sum( vapply( issue_events, function(x) x[["event"]] == "referenced" & !is.null(x[["commit_id"]]) , logical(1) ) )
#> [1] 2
from projmgr.
(As a sidenote, since it sounds like you might have been looking at viz_taskboard
, may I please point out the report_taskboard
alternative? I think it's new since you installed the package.
I'm experimenting with HTML-based visualization since the linking workflow is more seamless than ggplot and it also dynamically scales better to page size. The downside, of course, is that it only works in HTML output.
No pressure to look, but I certainly welcome any feedback on whether or not this seems useful compared to the plots!)
from projmgr.
Hey @konradmayer - I just got around to implementing this with a has_n_commits(events, n = 1)
function. Per my thoughts above, it does require the user to construct the events
dataframe first. Closing this for now, but if you're interested to check it out, I'd love to know what you think!
from projmgr.
Hi @emilyriederer, thanks for further polishing your package!
I tried your new taskview helper, but somehow don't manage to get my head around it.
When I use the function like that,
my_issues <- get_issues(my_repo, state = "all", since = "2019-01-01") %>% parse_issues()
my_events <- get_issue_events(my_repo, 14) %>% parse_issue_events()
viz_taskboard(my_issues, has_n_commits(my_events, n = 1))
I get the same result only showing issue 1 in the "in progress" category, no matter what issue number is chosen in get_issue_events()
, if at minimum a single commit is contained in the issue (an error as "no rows to aggregate" otherwise). This output is accompanied by a warning:
Warning message: In if (res != "") { : the condition has length > 1 and only the first element will be used
as res is a longer list.
It seems I don't really understand the intended workflow, as for my_events
I would assume I need a dataframe containing the referenced events of all the issues and not of a selected one, so something like the not working code below:
my_issues <- get_issues(my_repo, state = "all", since = "2019-01-01") %>% parse_issues()
my_events <-
map(my_issues$number, ~get_issue_events(my_repo, .x) %>%
parse_issue_events()) %>%
bind_rows()
viz_taskboard(my_issues, has_n_commits(my_events, n = 1))
Therefore I would expect a function similar to get_issue_events()
without a number
argument to construct the events dataframe. Could you point me to what I'm failing to understand?
from projmgr.
Hi @konradmayer -- Apologies for the slow reply and thank you for your kind and thoughtful reply. I had a bit of a conceptual mistake which made its way both into the has_n_commits()
code and the unit tests. So, everything superficially looked fine but the function was just simply wrong.
Even worse than that, you are completely right about the core behavior of get_issue_events()
not facilitating this workflow. I have also changed the default behavior there to return a dummy "existence" event for issues with no real events.
All should be working appropriately now. The reprex
below is based on the current state of my emilyriederer/experigit
repo which currently has two open issues: one with one commit and one with no commits.
library(projmgr)
repo <- create_repo_ref("emilyriederer", "experigit")
#> Requests will authenticate with GITHUB_PAT
issues <- get_issues(repo, state = "open") %>% parse_issues()
events <- purrr::map_df(issues$number, ~get_issue_events(repo, .x) %>% parse_issue_events())
has_n_commits(events, n = 0)(issues)
#> [1] TRUE TRUE
has_n_commits(events, n = 1)(issues)
#> [1] TRUE FALSE
has_n_commits(events, n = 2)(issues)
#> [1] FALSE FALSE
viz_taskboard(issues, in_progress_when = has_n_commits(events))
Created on 2019-09-01 by the reprex package (v0.3.0)
Thank you again so much for your patience and helpful feedback! It really means a lot.
from projmgr.
Related Issues (20)
- Wrong order of arguments HOT 1
- bug in report_progress() - problem with aggregate() HOT 3
- Ensure broader coverage of output in parse_issue_events HOT 1
- Support basic usage without PAT
- report_taskview() incorrect order and header HOT 4
- Add vignette on how to apply custom CSS to report_taskboard
- Add vignette on new labeling functions
- Error in post_plan: creates milestones but not issues and doesn't return data frame HOT 3
- Question: how to get closed issues from the get_issue function HOT 3
- typos in the examples HOT 1
- Wrapper for GitLab as well? HOT 3
- Add vignette comparing to GitHub Projects
- Test report_plan() total counts
- PATs need to have scopes HOT 1
- "per_page" is not a permitted key HOT 6
- Add taskboard_helper for has_comments
- Migrate to GitHub Actions and gh-pages branch for site
- Getting issues with multiple labels throws error
- Create update_issue()
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from projmgr.