add the following two workflows to your project:

https://github.com/r-lib/actions/blob/master/.github/workflows/check-standard.yaml

https://github.com/r-lib/actions/blob/master/.github/workflows/test-coverage.yaml

At time of submission, we expect that your project successfully runs these workflows.

include installation instructions in the README.Rmd file

examine Roxygen2 documentation of your functions to make sure it is clear

• The name of the repository should be relevant to the package/project topics.

• For now choose the MIT license. You may change it later when you learn more about licenses.

• Use usethis::use_code_of_conduct to add a code of conduct. You may want to customize it further to suit your group.

• Add the team members as authors to the DESCRIPTION file.

• Use usethis::use_tidy_contributing() to add a CONTRIBUTING.md file to your package. This file will live in .github and it will create that folder if it does not already exist. Edit the boiler plate document this gives to to reflect your contribution strategy that your team has agreed upon.

Outline the package you would like to build in the README.Rmd file. (This can be identical for both projects at this point in the project). In particular, your README.md should contain:

• a summary paragraph that describes the project at a high level

• a bulleted list of the functions (and datasets if applicable) that will be included in the package (this should be a 1-2 sentence description for each function/dataset)

• a paragraph describing where your packages fit into the R ecosystem (are there any other R packages that have the same/similar functionality? Provide links to any that do. If none exist, then clearly state this as well).

Write test cases and code iteratively

Before writing any code, revisit your function specifications from last week and revise them if needed. As you do this, think critically about what function inputs you expect from the user and what your function is supposed to do (e.g., return).

Write a unit tests for each specified function using testthat. test_that code blocks do not need to be wrapped in a function. Each function should have 3 to 5 edge cases tested to ensure that the function returns what is expected to the user. Group these test cases in a sensible way so that what is being tested matches the string associated with the test_that code blocks. This might mean that you may end up with 2-3 test_that code blocks per function. Remember, when writing your tests, build them around your function specifications and requirements.

After writing your unit tests, write the internal code for your R functions.

Write function code and tests in close temporal proximity with each other. The process of writing function code and test cases will be iterative; there will be several rounds of writing tests → function improvement → writing more tests → function improvement → writing more tests → function improvement, etc.

Make sure that the tests cover all branches (e.g., if your function has an if statement, you should have tests where the if statement is true, and where the if statement is false.

As you develop your code and test cases, update your code documentation so that it makes sense with any of the changes you have made. Do not forget to also document your test functions.

Check whether the code passes all the unit tests you have written using the devtools::test() function.

Exception handling

The function should be written defensively. That is, it should handle incorrect input and errors detected during execution via throwing exceptions with useful error messages, and there should be tests to confirm that the exceptions result in the expected behaviour of the function.

The URL for each of your public projects’ repositories

The URL to a release for each of your projects’ repositories

The URL to the issue that thoroughly discusses and reasons the license choice

The URL for each of your your public projects’ repositories

The URL to a release for each of your projects’ repositories

To do this, you should use vignette package-wide documentation in R, as well as the pkgdown R package to set up a website for your package.

include a full usage demonstration of all your package functions (this means a runnable example - give them data!) in your vignette

Complete the function specification for Rgram functions:

• 1. Flipping @mgaroub
• 2. Padding @wang-rui
• 3. Rotating @jiajie0225
• 4. Grayscale @AishwaryaGopal12

For this milestone you will write R function documentation that will serve as specifications, but you will NOT write any code for your package functions. Specifically, set-up empty functions (with appropriate function names) containing no code in the files where you will eventually write code. Write function documentation (e.g., complete roxygen2 comments). These are the functions you wrote about in your proposal.

Write test cases and code iteratively

Before writing any code, revisit your function specifications from last week and revise them if needed. As you do this, think critically about what function inputs you expect from the user and what your function is supposed to do (e.g., return).

Write a unit tests for each specified function using testthat. test_that code blocks do not need to be wrapped in a function. Each function should have 3 to 5 edge cases tested to ensure that the function returns what is expected to the user. Group these test cases in a sensible way so that what is being tested matches the string associated with the test_that code blocks. This might mean that you may end up with 2-3 test_that code blocks per function. Remember, when writing your tests, build them around your function specifications and requirements.

After writing your unit tests, write the internal code for your R functions.

Write function code and tests in close temporal proximity with each other. The process of writing function code and test cases will be iterative; there will be several rounds of writing tests → function improvement → writing more tests → function improvement → writing more tests → function improvement, etc.

Make sure that the tests cover all branches (e.g., if your function has an if statement, you should have tests where the if statement is true, and where the if statement is false.

As you develop your code and test cases, update your code documentation so that it makes sense with any of the changes you have made. Do not forget to also document your test functions.

Check whether the code passes all the unit tests you have written using the devtools::test() function.

Exception handling

The function should be written defensively. That is, it should handle incorrect input and errors detected during execution via throwing exceptions with useful error messages, and there should be tests to confirm that the exceptions result in the expected behaviour of the function.

Each team must initiate a review request by opening an issue per package in the UBC-MDS/software-review-2021 repository.

For initiating a reviewing request in R, use this template.

For initiating a reviewing request in Python, use the template under Submit Software for Review at this link.

(Details look at the milestone4 instruction)

Write test cases and code iteratively

Before writing any code, revisit your function specifications from last week and revise them if needed. As you do this, think critically about what function inputs you expect from the user and what your function is supposed to do (e.g., return).

Write a unit tests for each specified function using testthat. test_that code blocks do not need to be wrapped in a function. Each function should have 3 to 5 edge cases tested to ensure that the function returns what is expected to the user. Group these test cases in a sensible way so that what is being tested matches the string associated with the test_that code blocks. This might mean that you may end up with 2-3 test_that code blocks per function. Remember, when writing your tests, build them around your function specifications and requirements.

After writing your unit tests, write the internal code for your R functions.

Write function code and tests in close temporal proximity with each other. The process of writing function code and test cases will be iterative; there will be several rounds of writing tests → function improvement → writing more tests → function improvement → writing more tests → function improvement, etc.

Make sure that the tests cover all branches (e.g., if your function has an if statement, you should have tests where the if statement is true, and where the if statement is false.

As you develop your code and test cases, update your code documentation so that it makes sense with any of the changes you have made. Do not forget to also document your test functions.

Check whether the code passes all the unit tests you have written using the devtools::test() function.

Exception handling

The function should be written defensively. That is, it should handle incorrect input and errors detected during execution via throwing exceptions with useful error messages, and there should be tests to confirm that the exceptions result in the expected behaviour of the function.

Examine the license for your project and consider whether this is the choice you want to make, or whether you want to change the license. Discuss and reason the license choice by opening issues in both Python and R repositories. As it is likely to be a very similar discussion for both projects, one of these issues can just link to the other issue where it is thoroughly dicussed.

Same as UBC-MDS/imageprocessor#22

In the textbox provided on Canvas for the Milestone 2 assignment you must include:

The URL for each of your your public projects’ reposioties

The URL to a release for each of your projects reposoitories