This issue is a kind reminder that your repository has been inactive for 362 days. Some repositories are maintained in accordance with business requirements that infrequently change thus appearing inactive, and some repositories are inactive because they are unmaintained.

To help differentiate products that are unmaintained from products that do not require frequent maintenance, repomountie will open an issue whenever a repository has not been updated in 180 days.

• If this product is being actively maintained, please close this issue.
• If this repository isn't being actively maintained anymore, please archive this repository. Also, for bonus points, please add a dormant or retired life cycle badge.

Thank you for your help ensuring effective governance of our open-source ecosystem!

No Project Lifecycle Badge found in your readme!

Hello! I scanned your readme and could not find a project lifecycle badge. A project lifecycle badge will provide contributors to your project as well as other stakeholders (platform services, executive) insight into the lifecycle of your repository.

What is a Project Lifecycle Badge?

It is a simple image that neatly describes your project's stage in its lifecycle. More information can be found in the project lifecycle badges documentation.

What do I need to do?

I suggest you make a PR into your README.md and add a project lifecycle badge near the top where it is easy for your users to pick it up :). Once it is merged feel free to close this issue. I will not open up a new one :)

TL;DR

Topics greatly improve the discoverability of repos; please add the short code from the table below to the topics of your repo so that ministries can use GitHub's search to find out what repos belong to them and other visitors can find useful content (and reuse it!).

Why Topic

In short order we'll add our 800th repo. This large number clearly demonstrates the success of using GitHub and our Open Source initiative. This huge success means its critical that we work to make our content as discoverable as possible; Through discoverability, we promote code reuse across a large decentralized organization like the Government of British Columbia as well as allow ministries to find the repos they own.

What to do

Below is a table of abbreviation a.k.a short codes for each ministry; they're the ones used in all @gov.bc.ca email addresses. Please add the short codes of the ministry or organization that "owns" this repo as a topic.

That's in, you're done!!!

How to use

Once topics are added, you can use them in GitHub's search. For example, enter something like org:bcgov topic:citz to find all the repos that belong to Citizens' Services. You can refine this search by adding key words specific to a subject you're interested in. To learn more about searching through repos check out GitHub's doc on searching.

Pro Tip 🤓

• If your org is not in the list below, or the table contains errors, please create an issue here.

• While you're doing this, add additional topics that would help someone searching for "something". These can be the language used javascript or R; something like opendata or data for data only repos; or any other key words that are useful.

• Add a meaningful description to your repo. This is hugely valuable to people looking through our repositories.

• If your application is live, add the production URL.

Ministry Short Codes

NOTE See an error or omission? Please create an issue here to get it remedied.

No Project Lifecycle Badge found in your readme!

Hello! I scanned your readme and could not find a project lifecycle badge. A project lifecycle badge will provide contributors to your project as well as other stakeholders (platform services, executive) insight into the lifecycle of your repository.

What is a Project Lifecycle Badge?

It is a simple image that neatly describes your project's stage in its lifecycle. More information can be found in the project lifecycle badges documentation.

What do I need to do?

I suggest you make a PR into your README.md and add a project lifecycle badge near the top where it is easy for your users to pick it up :). Once it is merged feel free to close this issue. I will not open up a new one :)

This issue is a kind reminder that your repository has been inactive for 545 days. Some repositories are maintained in accordance with business requirements that infrequently change thus appearing inactive, and some repositories are inactive because they are unmaintained.

To help differentiate products that are unmaintained from products that do not require frequent maintenance, repomountie will open an issue whenever a repository has not been updated in 180 days.

• If this product is being actively maintained, please close this issue.
• If this repository isn't being actively maintained anymore, please archive this repository. Also, for bonus points, please add a dormant or retired life cycle badge.

Thank you for your help ensuring effective governance of our open-source ecosystem!

This issue is a kind reminder that your repository has been inactive for 181 days. Some repositories are maintained in accordance with business requirements that infrequently change thus appearing inactive, and some repositories are inactive because they are unmaintained.

To help differentiate products that are unmaintained from products that do not require frequent maintenance, repomountie will open an issue whenever a repository has not been updated in 180 days.

• If this product is being actively maintained, please close this issue.
• If this repository isn't being actively maintained anymore, please archive this repository. Also, for bonus points, please add a dormant or retired life cycle badge.

Thank you for your help ensuring effective governance of our open-source ecosystem!

In general when hosting packages on GitHub, we have a problem with how to best distribute vignettes. If we can come up with a good working solution here, I propose we add a bit to the wiki to describe it.

For this discussion I'm assuming vignettes are created as .Rmd files in the vignettes/ directory, with a .yaml header that looks like:

---
title: "Vignette Title"
author: "Vignette Author"
date: "`r Sys.Date()`"
output: rmarkdown::html_vignette
vignette: >
  %\VignetteIndexEntry{Vignette Title}
  %\VignetteEngine{knitr::rmarkdown}
  %\VignetteEncoding{UTF-8}
---

(The easiest way to create one is with usethis::use_vignette("vignette-title"))

The issue is that remotes::install_github() doesn't build vignettes automatically, so when a user installs a package from github, they can't run browseVignettes("pkgname") to access them. This is different to packages hosted on CRAN, where vignettes are pre-built and included when you run install.packages("cranpkgename").

Possible solutions:

1. In the installation section of the package README, make the instructions:

   install_github("bcgov/pkgname", build_opts = c("--no-resave-data", "--no-manual"))

   This works because the default of build_opts argument is c("--no-resave-data", "--no-manual", "--no-build-vignettes"), so the above removes the "--no-build-vignettes" flag, hence vignettes are built.

   From the developer perspective, this is easiest, as we don't have to do anything extra. From a user perspective however, I think it's less optimal - once a user becomes used to using install_github(), just typing install_github("bcgov/pkgname") becomes reflexive and they probably won't even look at the installation instructions in the README.

   The other downside of this is that if the vignettes are resource intensive to build, or require local files/infrastructure that aren't committed to the repo it will be either really slow, or won't work at all.

2. Build the vignettes and place the built artifacts (.Rmd, .R, .html) in inst/doc/. Then the built vignettes are included in the package and install_github("bcgov/pkgname") will just work for the user. This is how it is in bcgroundwater.

   The downside of this is that putting those files in inst/doc/ is a manual process that a developer will have to remember to do each time they update the package and/or the vignettes. In addition, devtools::install() will actually delete these files because it's now considered not good practice so we might be continuously fighting ourselves. We could write some functions (in bcgovr?) to help automate this...

3. Start to use the bcgov drat repository to host packages. Then the developer runs devtools::build() and deploys the built tar.gz to the drat repository (we could again add functions to automate this... I'm thinking bcgovr::deploy_drat()). Users then run install.packages("pkgname", repos = "https://bcgov.github.io/drat/") (or better yet has "https://bcgov.github.io/drat/" in their repos list in their .Rprofile) and it all works.

   The obvious downside is more overhead for developers. An additional upside (unrelated to vignettes) is that we have more control over package releases (i.e., separation of development in GitHub and versioned releases in drat). Also, users will be informed of package updates as they currently are for CRAN packages.

Whew! Did I miss anything? @stephhazlitt @boshek @jongoetz

Obvious

Hi, could you please add a LICENSE file your repo. All repositories in the BCGOV ORG are required to have a LICENSE file. Reference: https://github.com/bcgov/BC-Policy-Framework-For-GitHub/tree/master/BC-Gov-Org-HowTo and https://github.com/bcgov/BC-Policy-Framework-For-GitHub/blob/master/BC-Gov-Org-HowTo/Cheatsheet.md. Thank you.

This issue is a kind reminder that your repository has been inactive for 181 days. Some repositories are maintained in accordance with business requirements that infrequently change thus appearing inactive, and some repositories are inactive because they are unmaintained.

To help differentiate products that are unmaintained from products that do not require frequent maintenance, repomountie will open an issue whenever a repository has not been updated in 180 days.

• If this product is being actively maintained, please close this issue.
• If this repository isn't being actively maintained anymore, please archive this repository. Also, for bonus points, please add a dormant or retired life cycle badge.

Thank you for your help ensuring effective governance of our open-source ecosystem!

This issue is a kind reminder that your repository has been inactive for 180 days. Some repositories are maintained in accordance with business requirements that infrequently change thus appearing inactive, and some repositories are inactive because they are unmaintained.

To help differentiate products that are unmaintained from products that do not require frequent maintenance, repomountie will open an issue whenever a repository has not been updated in 180 days.

• If this product is being actively maintained, please close this issue.
• If this repository isn't being actively maintained anymore, please archive this repository. Also, for bonus points, please add a dormant or retired life cycle badge.

Thank you for your help ensuring effective governance of our open-source ecosystem!

No Project Lifecycle Badge found in your readme!

Hello! I scanned your readme and could not find a project lifecycle badge. A project lifecycle badge will provide contributors to your project as well as other stakeholders (platform services, executive) insight into the lifecycle of your repository.

What is a Project Lifecycle Badge?

It is a simple image that neatly describes your project's stage in its lifecycle. More information can be found in the project lifecycle badges documentation.

What do I need to do?

I suggest you make a PR into your README.md and add a project lifecycle badge near the top where it is easy for your users to pick it up :). Once it is merged feel free to close this issue. I will not open up a new one :)