I think this is really strong. Love that it's making GCIO, OCIO and ministry responsibilities much more clear - this was a strong recommendation coming out of the recent Comptroller General review of our Critical Systems Standard.

Attached are my suggestions to make it even a wee bit more clear and concise - happy to discuss if need be.
Ch12SuggestedEdits.docx

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!

Re #3: "Ensure that service provider contracts adequately address IM IT." I would suggest that it is not necessarily the responsibility of supervisors. While contract management/oversight is often responsibility of folks who are supervisors, it is not a one to one alignment with their supervision role.

Suggest that this responsibility be called out for procurement and/or contract management.

Related is definition of Supervisor in Section 12.4 - I believe combining employee reporting structure and a person managing a service provider contractor should be identified separately as the relationship is not the same, especially as contracts can be for products/services and not just people/resources.

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

Short Code	Organization Name
AEST	Advanced Education, Skills & Training
AGRI	Agriculture
ALC	Agriculture Land Commission
AG	Attorney General
MCF	Children & Family Development
CITZ	Citizens' Services
DBC	Destination BC
EMBC	Emergency Management BC
EAO	Environmental Assessment Office
EDUC	Education
EMPR	Energy, Mines & Petroleum Resources
ENV	Environment & Climate Change Strategy
FIN	Finance
FLNR	Forests, Lands, Natural Resource Operations & Rural Development
HLTH	Health
FLNR	Indigenous Relations & Reconciliation
JEDC	Jobs, Economic Development & Competitiveness
LBR	Labour Policy & Legislation
LDB	BC Liquor Distribution Branch
MMHA	Mental Health & Addictions
MAH	Municipal Affairs & Housing
BCPC	Pension Corporation
PSA	Public Safety & Solicitor General & Emergency B.C.
SDPR	Social Development & Poverty Reduction
TCA	Tourism, Arts & Culture
TRAN	Transportation & Infrastructure

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

Is there some way to further clarify what practical steps the average employee can take to know if they're acting in an ethical manner?

In the Overview there's a general instruction to employees to "...act in an ethical manner..." followed by a suggestion that testing one's actions against the BC-PS Corporate Values will help employees act ethically.

But what should the average employee do when the application of one of those values/principles is unclear in a certain situation? What if two or more of those values/principles seem to be in conflict in a certain situation? What if different employees come from different backgrounds and can't agree on the interpretation of the corporate values?

So it might be tricky for the average employee to know if they're succeeding at acting "...in an ethical manner...". Ethics isn't mentioned again in the policy, and isn't in the definitions. And that sense of "values" isn't used again in the policy either.

Perhaps the simplest solution is a command to reach out to the Corporate Ethics Advisory Service when in doubt or conflict?

To look a little farther I did a quick scan for practical suggestions on how to act ethically. One source that seemed somewhat relevant was the Ethics in Law Enforcement textbook on the BC Open Textbooks site. The authors Rick Parent and Steve McCartney are Canadian and BC based. A search of the book reveals some advice in Chapter 1 that everyone must continuously practice acting "morally" and "virtuously" and 'do unto others as you would have them do unto you'. But I'm not certain that is sufficient clarification, and it seems to suggest a certain socio-cultural context. Perhaps there are other practical suggestions later in this book or in other publications?

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 :)

Good Morning,

We are pleased to announce that this updated Core Policy and Procedures Manual Policy (CPPM) Chapter 12: Information Management and Information Technology Management was released on May 5, 2022. Chapter 12 sets a policy framework for the best use of information and technology resources in government. Updates to this chapter were needed since the IM IT landscape has changed considerably since the policy was first created in 2006.

This new CPPM Chapter 12 aligns with government’s Digital Framework and benefits our teams in a few exciting ways:

• It removes the requirement to outsource technology development to the private sector. This will reduce the dependence on vendors and support greater investment in our digital workforce.

• It sets the expectation that ministries will use common components when building products and services. This will help avoid duplication of functionality across government's 1800+ applications.

• Aligning with Agile principles, the policy removes the expectation that system requirements for major IM IT projects be defined up front. Instead, products and services should be built iteratively based on user feedback. This will reduce the risk of IM IT project failures.

• Also, CPPM Chapter 12 sets the expectation that products and services should be designed, built, and tested with users. This will result in products and services that better meet peoples' needs.

I encourage you to take a few minutes to review the policy to see how it may relate to your day-to-day work.

Questions on Chapter 12 can be directed to [email protected].

General questions about Core Policy, can be directed to [email protected].

Before closing, we would like to thank everyone who took the time and effort to contribute to this important and innovative update to Chapter 12. In particular, we would like to recognize the Strategic Policy and Legislation Branch of the Corporate Information and Records Management Office for leading this agile policy development.

12.3.4 – The expectations around enterprise solutions are described in various ways

• they will be used when “practicable” (para2)
• when “possible” (para 4)
• use “reasonable efforts” (para 5)

I infer that the intent in these is all that we apply a test of reasonableness, but para’s 2 & 4 really speak to the test being whether or not it is impossible. (Compare meanings of “practicable” vs “practical”.)

I suggest that in each of these cases we adopt language of “reasonable”.

When I read the requirements under this section, I feel that there is a conflation of 'Open' with 'sharing' of data and information.

Open generally means unrestricted and unencumbered access public access to data and information with appropriate licensing (such as the OGL-BC). Sharing in the context as I read it refers to the ability for ministries and partners to access data to and from each other in a way to increase the value and use of the data.

A few suggestions:

1. To reduce the conflation of topics, I think that the concept of sharing could fit into 12.3.4 by increasing scope to Enterprise solutions including re-use and sharing of data (it is lightly mentioned in data registers)
2. While recognition of open is important - I suggest it be contextualized as open with a purpose and defined value. There is a cost associated with 'efforts to expand public access' and without additional resources, it is difficult and may not derive value. There can be cynicism and resultant negative effect of statements that 'ministries must' without providing the necessary resources to meet the need. I recommend a structure of proportionality or a spectrum of open and access as there can be value of open to portion of data and information without the challenges that setting the goal post of full open can lead to, which again can have negative consequences and limiting any action.