Git Product home page Git Product logo

projmgr's Introduction

CRAN status lifecycle Travis-CI Build Status AppVeyor build status Coverage status CRAN Downloads

projmgr

projmgr aims to better integrate project management into your workflow and free up time for more exciting tasks like R coding and data analysis. Since many R users and programmers use GitHub as a home for their analysis, the goal of projmgr is to streamline project management with these same tools.

Key functionalities include:

  • exchanging data with the GitHub API using user-friendly syntax
  • generating issues and milestones from plain text (YAML) or R objects
  • communicating (with reports or charts) project plans and progress to non-technical (non-GitHub using) collaborators

Just like communicating analytical results, good process communication is the key to success in most applied analysis settings. However, ad hoc processes or alternative tools can knock an analyst out of their R-based workflow and distract them from their core goals.

Try before you buy!

Want to find out more about projmgr before you install? Check out the package website for an overview of features and example use cases.

Installation

You can install projmgr on CRAN with:

install.packages("projmgr")

Alternatively, you can install the most up-to-ddate development version of projmgr with:

devtools::install_github("emilyriederer/projmgr")

Please see the NEWS.md file or the News page on the website for details of major differences.

Contributors

Thanks to contributors. Most notably, thanks to Konrad Mayer and Sam Tyner for proactive reporting and debugging of issues.

Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.

projmgr's People

Contributors

andrie avatar emilyriederer avatar olivroy avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

projmgr's Issues

new taskview_helper using number of commits

As commits are the best indication whether an issue is in progress I would suggest an additional function to taskview_helpers().

I put together a fast example of what I'm intending (altough not reproducible as I don't show how to get my_repo). get_n_commits() of course needs to be adopted as its rather slow this way and you probably don't want to import anything from purrr, its just there for illustration purposes.

issues <- 
  get_issues(my_repo, state = 'all', since = '2018-12-01') %>% 
  parse_issues() %>%
  arrange(milestone_number)

get_n_commits <- function(ref, issuenr) {
  purrr::map(issuenr, ~length(unlist(purrr::pluck(purrr::transpose(get_issue_events(ref, .x)), "commit_id"))))
}

issues <- issues %>% 
  mutate(n_commits = get_n_commits(my_repo, number))

has_n_commits <- function(n) {
  function(data) {
    stopifnot("n_commits" %in% names(data))
    vapply(data$n_commits, FUN = function(x) x >= 
             n, FUN.VALUE = logical(1)) 
  }
}

viz_taskboard(issues, has_n_commits(1))

Wrapper for GitLab as well?

Hi! Love the package, really well done ๐Ÿ˜„

I use both GitLab and GitHub probably about equally. There are lots of R packages to interact with GitHub, but not so much with GitLab. Given most of the functionality of projmgr is "neutral-language", it would theoretically be possible to connect to GitLab as well without changing projmgr's API.

Would that be something you'd consider adding (if a PR was submitted that is ๐Ÿ˜‰)? I'm planning on making some type of functionality or package like this in the near future (or contributing to the gitlabr package, which seems to not be actively maintained or developed). So if its something you'd be interested in adding, I'd be happy to help contribute to projmgr with this.

Should multi-value fields be included in parse fxs as list-columns or relegated to separate tables?

Current parse functions like parse_issues() create list-columns for fields like assignees_login and labels_name which can take multiple values. This can be convenient in some cases, but could also lead to unexpected problems. For example, if a user unknowingly unnests this data, then the dataset is no longer one observation per issue.

The alternative would be to take more of a database approach (1NF?) by excluding assignees and labels from the output of parse_issues() and adding separate parse_issue_assignees() and parse_issue_labels() functions which could then be filtered to specification and left-joined back on.

bug in report_progress() - problem with aggregate()

As aggregate() coerces to factor the ordering of groups doesn't necessary match the ordering of milestone_title.

projmgr/R/report.R

Lines 32 to 35 in 341c2a9

issue_closed_count <-
stats::aggregate(df$state,
by= list(df$milestone_title) ,
FUN= function(x) sum(x == 'closed'))$x

projmgr/R/report.R

Lines 45 to 47 in 341c2a9

issue_html_grp <- stats::aggregate(issue_html,
by = list(df$milestone_title),
FUN = function(x) paste(x, collapse = " "))$x

I will file a PR as soon as I find time for it.

PATs need to have scopes

I've really enjoyed spinning the wheels on this package, it seems very useful. I ran into trouble when first trying it. It appears that when creating a PAT, you need to check some of the boxes for correct authorization. I think this only requires a tiny change to the article (
https://emilyriederer.github.io/projmgr/articles/github-pat.html)

I apologize if the reprexes are too long, I was trying to be thorough. This is with a PAT with no scope boxes checked.

library(projmgr)

cfr_plan_txt <- "
- title: 2009 is a problem
  description: >
    The 2009 files continue to display weird results
  issue:
    - title: Investigate issue
      body: Not sure about path
      assignees: [willwheels]
      labels: [long-term]


- title: Redo network
  description: >
    Recreate network with tidygraph; do all data steps in initial dataframe
  issue:
    - title: Remove igraph steps
      body: nuke igraph
    - title: Move data steps
      body: Move all weight and size calculations to data frame creation
    - title: Visualizations
      body: recreate network visualizations"

cfr_plan <- read_plan(cfr_plan_txt)

cfr_repo_ref <- create_repo_ref("willwheels", "CFR")
#> Requests will authenticate with GITHUB_PAT

check_credentials(cfr_repo_ref)
#> -- With provided credentials -- 
#> + Login: willwheels
#> + Type: User
#> -- In the CFR repo -- 
#> + Admin: FALSE
#> + Push: FALSE
#> + Pull: FALSE

cfr_plan
#> Plan: 
#> 1. 2009 is a problem (1 issues) 
#> 2. Redo network (3 issues)

cfr_repo_ref
#> + Repository Owner: willwheels
#> + Repository: CFR
#> + From URL: https://api.github.com/
#> + Authenticating with: GITHUB_PAT

post_plan(cfr_repo_ref, cfr_plan)
#> Error in gh::gh(endpoint = paste0(ref$base_url, ref$repo_path, api_endpoint), : GitHub API error (404): 404 Not Found
#>   Not Found

Created on 2020-05-20 by the reprex package (v0.3.0)

Then, created a new PAT, checking the boxes for "repo" and "workflow" and it worked:

library(projmgr)

cfr_plan_txt <- "
- title: 2009 is a problem
  description: >
    The 2009 files continue to display weird results
  issue:
    - title: Investigate issue
      body: Not sure about path
      assignees: [willwheels]
      labels: [long-term]


- title: Redo network
  description: >
    Recreate network with tidygraph; do all data steps in initial dataframe
  issue:
    - title: Remove igraph steps
      body: nuke igraph
    - title: Move data steps
      body: Move all weight and size calculations to data frame creation
    - title: Visualizations
      body: recreate network visualizations"

cfr_plan <- read_plan(cfr_plan_txt)

cfr_repo_ref <- create_repo_ref("willwheels", "CFR")
#> Requests will authenticate with GITHUB_PAT

check_credentials(cfr_repo_ref)
#> -- With provided credentials -- 
#> + Login: willwheels
#> + Type: User
#> -- In the CFR repo -- 
#> + Admin: TRUE
#> + Push: TRUE
#> + Pull: TRUE

cfr_plan
#> Plan: 
#> 1. 2009 is a problem (1 issues) 
#> 2. Redo network (3 issues)

cfr_repo_ref
#> + Repository Owner: willwheels
#> + Repository: CFR
#> + From URL: https://api.github.com/
#> + Authenticating with: GITHUB_PAT

post_plan(cfr_repo_ref, cfr_plan)
#>   milestone_number   milestone_title issue_number         issue_title
#> 1                1 2009 is a problem            5   Investigate issue
#> 2                2      Redo network            6 Remove igraph steps
#> 3                2      Redo network            7     Move data steps
#> 4                2      Redo network            8      Visualizations

Created on 2020-05-20 by the reprex package (v0.3.0)

Question: how to get closed issues from the get_issue function

I find the get_issue function only return the open issues for some repo.
Here is the reproducible minimal example from a repo I create in public.
Currently, there are 29 open issues, here is the issue board link https://github.com/JiaxiangBU/tutoring/issues.

library(projmgr)
library(magrittr)
repo <- create_repo_ref("JiaxiangBU", "tutoring")
#> Requests will authenticate with GITHUB_PAT
issue_list <- get_issues(repo) %>% parse_issues()
nrow(issue_list)
#> [1] 28

Created on 2019-07-06 by the reprex package (v0.2.1)

Session info
devtools::session_info()
#> โ”€ Session info โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
#>  setting  value                       
#>  version  R version 3.5.3 (2019-03-11)
#>  os       macOS Mojave 10.14.5        
#>  system   x86_64, darwin15.6.0        
#>  ui       X11                         
#>  language (EN)                        
#>  collate  zh_CN.UTF-8                 
#>  ctype    zh_CN.UTF-8                 
#>  tz       Asia/Shanghai               
#>  date     2019-07-06                  
#> 
#> โ”€ Packages โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
#>  package     * version    date       lib
#>  assertthat    0.2.0      2017-04-11 [1]
#>  backports     1.1.2      2017-12-13 [1]
#>  base64enc     0.1-3      2015-07-28 [1]
#>  callr         3.0.0      2018-08-24 [1]
#>  cli           1.0.1      2018-09-25 [1]
#>  crayon        1.3.4      2017-09-16 [1]
#>  curl          3.3.9000   2019-06-07 [1]
#>  desc          1.2.0      2018-05-01 [1]
#>  devtools      2.0.1      2018-10-26 [1]
#>  digest        0.6.18     2018-10-10 [1]
#>  evaluate      0.12       2018-10-09 [1]
#>  fs            1.3.1      2019-05-06 [1]
#>  gh            1.0.1      2017-07-16 [1]
#>  glue          1.3.1      2019-03-12 [1]
#>  highr         0.7        2018-06-09 [1]
#>  htmltools     0.3.6      2017-04-28 [1]
#>  httr          1.4.0      2018-12-11 [1]
#>  jsonlite      1.6        2018-12-07 [1]
#>  knitr         1.22.8     2019-05-14 [1]
#>  magrittr    * 1.5        2014-11-22 [1]
#>  memoise       1.1.0      2017-04-21 [1]
#>  pkgbuild      1.0.2      2018-10-16 [1]
#>  pkgload       1.0.2      2018-10-29 [1]
#>  prettyunits   1.0.2      2015-07-13 [1]
#>  processx      3.2.0      2018-08-16 [1]
#>  projmgr     * 0.0.0.9902 2019-05-25 [1]
#>  ps            1.2.1      2018-11-06 [1]
#>  R6            2.3.0      2018-10-04 [1]
#>  Rcpp          1.0.0      2018-11-07 [1]
#>  remotes       2.0.2      2018-10-30 [1]
#>  rlang         0.3.1      2019-01-08 [1]
#>  rmarkdown     1.10       2018-06-11 [1]
#>  rprojroot     1.3-2      2018-01-03 [1]
#>  sessioninfo   1.1.1      2018-11-05 [1]
#>  stringi       1.4.3      2019-03-12 [1]
#>  stringr       1.4.0      2019-02-10 [1]
#>  testthat      2.0.0      2017-12-13 [1]
#>  usethis       1.5.0      2019-04-07 [1]
#>  withr         2.1.2      2018-03-15 [1]
#>  xfun          0.6        2019-04-02 [1]
#>  yaml          2.2.0      2018-07-25 [1]
#>  source                                
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.0)                        
#>  Github (jeroen/curl@2f1d497)          
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.1)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.2)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.2)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.0)                        
#>  Github (yihui/knitr@00ffce2)          
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.0)                        
#>  Github (emilyriederer/projmgr@d7184ce)
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.2)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.2)                        
#>  CRAN (R 3.5.2)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.3)                        
#>  CRAN (R 3.5.0)                        
#>  CRAN (R 3.5.2)                        
#>  CRAN (R 3.5.0)                        
#> 
#> [1] /Library/Frameworks/R.framework/Versions/3.5/Resources/library

Getting issues with multiple labels throws error

When importing an issue with multiple labels, the parsing process throws an error.

The reprex reads an issue from a public repo. One of the issues has multiple labels.

image

library(projmgr)
my_repo <- create_repo_ref('andrie', 'spanner')
#> Requests will authenticate with GITHUB_PAT
get_issues(my_repo, state = 'open') %>% parse_issues()
#> Error in `$<-.data.frame`(`*tmp*`, "labels_name", value = structure(c("bug", : replacement has 2 rows, data has 1

Created on 2022-12-02 with reprex v2.0.2

I have a fix and will provide a PR soon. The fix requires that the issues$labels_name column is a list column.

typos in the examples

projmgr/R/parse.R

Lines 17 to 19 in e29951c

#' myrepo <- create_repo_reference('emilyriederer', 'myrepo')
#' issues_res <- get_issues(myrepo)
#' issues <- parse_issues(issues_res)

Here create_repo_reference should be create_repo_ref.

On failure, should post_ functions revert any partial changes?

Currently, post_ functions (specifically multi-step ones like post_plan and post_todo) could partially succeed and then error out, leaving the repo in a confusing in-between state. Consider implementing one of the following solutions:

  • At minimum, explicitly inform user what partial changes were made
  • Better, revert any partial changes if any part of command should fail
    • Delete created milestones
    • Close created issues - possibly with explanatory commentary
  • Optimally, test each step before executing and only execute if can succeed completely

Separate thought should be given to the best UX when failure is due to duplication. Should post_ functions be allowed to succeed? If a milestone with a conflicting title already exists, should new issues be added to the old milestone?

"per_page" is not a permitted key

Hi,
Love the idea behind this and looking forward to using the package.

I have been trying to follow along but cannot use the function post_plan() and have been getting the following error:

Error in gh_process_response(raw) : 
GitHub API error (422): 422 Unprocessable Entity
Message: Invalid request.

"per_page" is not a permitted key.

From reading #42 I thought this may have had something to do with scopes when setting up the PAT. I have tried:

  • Not specifying any scope

  • Specifying gist and repo

  • Specifying repo and workflow

  • Specifying all scopes

Credentials check seems ok:

-- With provided credentials -- 
+ Login: Bartesto
+ Type: User
-- In the rivRmon_development repo -- 
+ Admin: TRUE
+ Push: TRUE
+ Pull: TRUE

And I can use post_issue and post_todo without any problems.

Thanks
Bart

Support basic usage without PAT

Add to create_repo_ref and the API engines to support basic usage event if no GitHub PAT is available. Users would not be able to post anything and would have a lower rate limit, but this could allow them to try the get, viz, and report functions.

Removing this PAT "barrier to entry" facilitates initial package exploration and some complete workflows (when focus is on communication versus planning.)

report_taskview() incorrect order and header

When I include report_taskview() in rmarkdown, all the categories (not started, in progress, done) are at the top of the taskview followed by the issues in random order. Works correctly in viz_taskview() and I only checked for issues and not for milestones.

Error in post_plan: creates milestones but not issues and doesn't return data frame

Sorry for this but I'm going insane. I'm sure it's just some dumb little YAML thing like an extra space or something but I cannot figure out for the life of me what is going on.

I copy-pasted your example from here to make a new plan. It worked great. (See okay below.)

Then I tried making my own, and totally failed. Well, not totally: the milestones were there but not the issues. There was an error message: #> Error in do.call(post_local, x): second argument must be a list and the data frame didn't print off at the end.

Then, I tried using the template and copy-pasting. (See broken below.) It STILL didn't work. (And now I have an additional error: #> Warning in mapply(FUN = function(x, y) {: longer argument not a multiple of length of shorter

I ended up stepping through all of your code, and everything seems to explode when the issues object is created in post_plan.

Do you have any clue why it's doing this? I'm seriously losing it because I am sure it's a simple YAML spacing thing or SOMETHING and I'm going nuts. Enjoy my reprex? ๐Ÿคทโ€โ™€ Here are some screengrabs of the result on github.
only_some_issues_created
all-milestones-created

library(projmgr)
# connect to repo (emily i added you just in case)
my_ref <- create_repo_ref("sctyner", "magic-tidying-data")
#> Requests will authenticate with GITHUB_PAT

# run to make sure you can read/write
check_credentials(my_ref)
#> -- With provided credentials -- 
#> + Login: sctyner
#> + Type: User
#> -- In the magic-tidying-data repo -- 
#> + Admin: TRUE
#> + Push: TRUE
#> + Pull: TRUE

# yaml examples 

broken <-"- title: Enter a short, informative title of your goal
  description: >
    Enter a longer description of the objectives
  due_on: 2018-12-31T12:59:59Z
  issue:
    - title: Title of task 1 to complete
      body: Describe this step
      assignees: [sctyner]
      labels: [a, b, c]
    - title: Title of task 2 to comple
      body: Describe this step
      labels: [low]

- title: Enter another short, informative title of your goal
  description: >
    Enter a longer description of the objectives
  issue:
    - title: Title of task 1 to complete
      body: Describe this step
    - title: Title of task 2 to complete
      body: Describe this step
"

okay <- "- title: Data cleaning and validation
  description: >
    We will conduct data quality checks,
    resolve issues with data quality, and
    document this process
  due_on: 2018-12-31T12:59:59Z
  issue:
    - title: Define data quality standards
      body: List out decision rules to check data quality
      assignees: [sctyner]
      labels: [a, b, c]
    - title: Assess data quality
      body: Use assertthat to test decision rules on dataset
      labels: [low]
    - title: Resolve data quality issues
      body: Conduct needed research to resolve any issues

- title: Exploratory data analysis
  description: >
    Create basic statistics and views to better
    understand dataset and relationships
  issue:
    - title: Summary statistics
      body: Calculate summary statistics
    - title: Visualizations
      body: Create univariate and bivariate plots
"

my_plan <- read_plan(broken)
er_plan <- read_plan(okay)

# comparing my_plan and er_plan
is.list(my_plan)
#> [1] TRUE
my_plan
#> Plan: 
#> 1. Enter a short, informative title of your goal (2 issues) 
#> 2. Enter another short, informative title of your goal (2 issues)
er_plan
#> Plan: 
#> 1. Data cleaning and validation (3 issues) 
#> 2. Exploratory data analysis (2 issues)

milestones <- lapply(my_plan,
                     FUN = function(x) x[intersect( names(x), c("title", help_post_milestone()) )])
milestones
#> [[1]]
#> [[1]]$title
#> [1] "Enter a short, informative title of your goal"
#> 
#> [[1]]$description
#> [1] "Enter a longer description of the objectives\n"
#> 
#> [[1]]$due_on
#> [1] "2018-12-31T12:59:59Z"
#> 
#> 
#> [[2]]
#> [[2]]$title
#> [1] "Enter another short, informative title of your goal"
#> 
#> [[2]]$description
#> [1] "Enter a longer description of the objectives\n"

milestoneser <- lapply(er_plan,
                       FUN = function(x) x[intersect( names(x), c("title", help_post_milestone()) )])
milestoneser
#> [[1]]
#> [[1]]$title
#> [1] "Data cleaning and validation"
#> 
#> [[1]]$description
#> [1] "We will conduct data quality checks, resolve issues with data quality, and document this process\n"
#> 
#> [[1]]$due_on
#> [1] "2018-12-31T12:59:59Z"
#> 
#> 
#> [[2]]
#> [[2]]$title
#> [1] "Exploratory data analysis"
#> 
#> [[2]]$description
#> [1] "Create basic statistics and views to better understand dataset and relationships\n"

issues_per_milestone <- vapply(my_plan, FUN = function(x) length(x[["issue"]]), FUN.VALUE = integer(1), USE.NAMES = FALSE )
issues_per_milestone
#> [1] 2 2

issues_per_milestoneer <- vapply(er_plan, FUN = function(x) length(x[["issue"]]), FUN.VALUE = integer(1), USE.NAMES = FALSE )
issues_per_milestoneer
#> [1] 3 2

milestone_title <- vapply(milestones, FUN = function(x) x[["title"]], FUN.VALUE = character(1))
milestone_title
#> [1] "Enter a short, informative title of your goal"      
#> [2] "Enter another short, informative title of your goal"


milestone_titleer <- vapply(milestoneser, FUN = function(x) x[["title"]], FUN.VALUE = character(1))
milestone_titleer
#> [1] "Data cleaning and validation" "Exploratory data analysis"

# here is where it explodes 
issues <- unlist( sapply(my_plan, FUN = function(x) x[["issue"]]), recursive = FALSE )
issueser <- unlist( sapply(er_plan, FUN = function(x) x[["issue"]]), recursive = FALSE )
issues
#> $title
#> [1] "Title of task 1 to complete"
#> 
#> $body
#> [1] "Describe this step"
#> 
#> $assignees
#> [1] "sctyner"
#> 
#> $labels
#> [1] "a" "b" "c"
#> 
#> $title
#> [1] "Title of task 2 to comple"
#> 
#> $body
#> [1] "Describe this step"
#> 
#> $labels
#> [1] "low"
#> 
#> $title
#> [1] "Title of task 1 to complete"
#> 
#> $body
#> [1] "Describe this step"
#> 
#> $title
#> [1] "Title of task 2 to complete"
#> 
#> $body
#> [1] "Describe this step"
issueser
#> [[1]]
#> [[1]]$title
#> [1] "Define data quality standards"
#> 
#> [[1]]$body
#> [1] "List out decision rules to check data quality"
#> 
#> [[1]]$assignees
#> [1] "sctyner"
#> 
#> [[1]]$labels
#> [1] "a" "b" "c"
#> 
#> 
#> [[2]]
#> [[2]]$title
#> [1] "Assess data quality"
#> 
#> [[2]]$body
#> [1] "Use assertthat to test decision rules on dataset"
#> 
#> [[2]]$labels
#> [1] "low"
#> 
#> 
#> [[3]]
#> [[3]]$title
#> [1] "Resolve data quality issues"
#> 
#> [[3]]$body
#> [1] "Conduct needed research to resolve any issues"
#> 
#> 
#> [[4]]
#> [[4]]$title
#> [1] "Summary statistics"
#> 
#> [[4]]$body
#> [1] "Calculate summary statistics"
#> 
#> 
#> [[5]]
#> [[5]]$title
#> [1] "Visualizations"
#> 
#> [[5]]$body
#> [1] "Create univariate and bivariate plots"

post_plan(my_ref, my_plan)
#> Warning in mapply(FUN = function(x, y) {: longer argument not a multiple of
#> length of shorter
#> Error in do.call(post_local, x): second argument must be a list
post_plan(my_ref, er_plan)
#>   milestone_number              milestone_title issue_number
#> 1                3 Data cleaning and validation            1
#> 2                3 Data cleaning and validation            2
#> 3                3 Data cleaning and validation            3
#> 4                4    Exploratory data analysis            4
#> 5                4    Exploratory data analysis            5
#>                     issue_title
#> 1 Define data quality standards
#> 2           Assess data quality
#> 3   Resolve data quality issues
#> 4            Summary statistics
#> 5                Visualizations

Created on 2019-05-02 by the reprex package (v0.2.1)

Should repo name and repo owner be appended to get_ function outputs?

In some cases, it would be helpful if repo name and repo owner were return with get_ and parse_ outputs.

For example, when mapping over a list of repo refs, this would help simplify code from

milestone_lists <- purrr::map(repo_refs, get_milestones)
milestones <- purrr::map_dfr(milestone_lists, parse_milestones, .id = 'team')

to

milestone_lists <- purrr::map(repo_refs, get_milestones)
milestones <- purrr::map_dfr(milestone_lists, parse_milestones)

(Essentially eliminating the need for users to know about purrr's .id argument, and providing potentially more useful names than an index alone.)

However, this could be unnecessarily bulky and inconvenient for the (probably more common?) use case of working with a single repo at a time. (Given that generally design decisions have taken the "repo as first-class citizen" stance.)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.