Issue submission metrics are tracked on a dashboard

Generate dashboard to track:
- Number of issues each month/quarter.
- Breakdown by status (e.g. No response, Confirmed, Wishlist, Resolved.)
- Time to first response.
- Average time to final resolution (e.g. Closed, Resolved.)
- Top contributors (CyberArk staff and community members.)

A template repository exists

The template repository should include:

README.md with instructions on getting started (that are deleted on copying)
LICENSE
CONTRIBUTING.md
template Jenkinsfile
issue templates
PR templates
...

Public repositories have issue templates

Standard issue templates have been added to all public repositories

AC:

The default templates have been updated with actual default Bug and Feature Request templates
Each public repo has at minimum a Bug and Feature Request issue template

The community guidelines have undergone XA

Turn on master branch daily builds for all product repos we own

Add daily build triggers to the Jenkinsfile for any repos in this list that have pipelines but don't already have it turned on:

conjurdemos/cloudfoundry-conjur-demo
conjurdemos/kubernetes-conjur-demo
conjurdemos/pet-store-demo
conjurinc/cloudfoundry-conjur-tile
cyberark/ansible-conjur-host-identity
cyberark/cloudfoundry-conjur-buildpack
cyberark/conjur-puppet
cyberark/conjur-service-broker
cyberark/sidecar-injector
cyberark/terraform-provider-conjur
conjurinc/secretless-broker-e2e-tests
conjurinc/secretless-demo
conjurinc/secretless-server
cyberark/go-mssqldb
cyberark/secretless-broker
conjurinc/summon-chefapi
conjurinc/summon-conjurcli
conjurinc/summon-keyring
conjurinc/summon-s3
cyberark/summon
cyberark/summon-aws-secrets
cyberark/summon-conjur
cyberark/summon-file

Daily pipeline builds can be turned on by adding

triggers {
  cron(getDailyCronString())
}

to the Jenkinsfile

There is an automated process to validate and update acknowledgements files

Each public repository should include an open source acknowledgements file that is kept up-to-date with the OSS dependencies in the project

Create initial repository structure with README and team folders

AC:

The cyberark/community repo has a README that:
- Introduces CyberArk Commons and has a "Welcome to CyberArk Commons" message
- Refers to Discourse, conjur.org, blogs.conjur.org
- Talks about the three primary groups that have software in the cyberark GitHub org, and links to READMEs in separate folders for those three groups. There should be a bullet for each group that is involved - CyberArk Labs, CyberArk Conjur, and CyberArk Cloud Solutions - and the bullets should each link to a README in a folder for each group (eg labs, conjur, and cloud).

Once this is merged and live in the repo, we'll ask PMM for feedback on the main community README, and alert the cloud and lab teams to let them know to add content to their folders

Community repo describes the public issue tracking process

We may need to define this process for the OSS community first. Suggested flow:

Deliver internal issue tracking for public issues (in GitHub):
- Set up statuses.
- Set up any issue templates (e.g. for support issus to be redirected to Discourse.)
Deliver internal issue tracking for private issues (in GitHub):
- Set up statuses.

The updated GCP marketplace integration has gone through XA

Public repositories have a valid, up-to-date acknowledgements file

A first OSS suite release exists

AC:
There is an initial OSS suite release with:

CHANGELOG in the repo
GitHub tag and release with release notes
Updated documentation and release notes published on conjur.org

Repo has bug and feature request issue templates

AC:
The following templates have been added to the repo, with appropriate component labels:

Community repo has been reviewed by a future contributor

We'd love to have a future contributor look through the community repo and give us feedback on what could be clearer and how we can improve it.

Conjur README has guidelines on filing GitHub issues

TBD - depends on whether the github landing page is live. If so, we can advise to find the appropriate repository's issue page and click "new issue". Otherwise we may need to come up with more generic guidelines.

Public repos have issue templates

All public repos have bug and feature request issue templates.

Suggested templates:

Repos:

Secretless has run MSSQL performance tests with the latest master build (1.5.2-434b05c at this time)

AC:

Juxtaposer 1 hour, single thread, recreateConnections=false (aka persistent connection) performance tests have been run for MSSQL in a realistic environment (eg the XA env)
The tabular results of the performance tests have been attached to this issue

A blog post exists for running demos using KinD

@diverdane recently did a POC of revising the [Secretless demo](https://github.com/cyberark/secretless-broker/tree/master/demos/k8s-demo/] to run using KinD: https://github.com/diverdane/secretless-k8s-demo

This would make an interesting blog post. Some points to consider hitting:

the evolution of local K8s dev
the differences between KinD and other options
considerations when choosing a local tool to try k8s
whether you'd use KinD for local dev if you have access to an actual k8s cluster

All public repos have master branch protection on

All public repos should require pull requests for submitting code to the master branch.

AC:

Review all public repos to determine master branch protection status
Turn on master branch protection (with re-review required if new changes are pushed) if a repository does not yet have it on

Code review process is published

AC:

Finalize how PRs are reviewed (applying to both staff and community members.)
Document this process on conjur.org and in the community repo

Broken Terraform build is fixed

The broken terraform provider build here needs to be fixed.

Suite release has undergone XA

User Stories

Open Source Users


As a	Conjur Open Source user
I want	to know what tools and integrations there are for Conjur
so that	I can evaluate whether Conjur is suitable for me to use, and which tools / integrations are compatible with my systems.


As a	Conjur Open Source user
I want	to know what versions of Conjur OSS components to use
so that	I am using reliable, well-tested software that works together as expected when used within my systems.

OSS Suite Component Maintainers


As a	maintainer of a Conjur OSS suite component
I want	to know how to ensure new versions of my component get into the OSS suite release
so that	OSS users can benefit from new features my team is adding to our component.


As a	maintainer of a Conjur OSS suite component
I want	to know what I'm responsible for testing and what will be tested in the OSS suite
so that	it's clear what tests I need to include and maintain in my component repository, and which tests belong in the central OSS suite release repo.


As a	maintainer of a Conjur OSS suite component
I want	to know what standards I need to maintain in my repository
so that	my CHANGELOG entries, releases, READMEs, etc are compatible with the OSS suite release.

Conjur OSS Contributors


As a	Conjur Open Source contributor
I want	to know what components there are
so that	I can find components that I can contribute to.


As a	Conjur Open Source contributor
I want	to know what is included in the Conjur OSS suite
so that	if there are tools or platforms that are not supported, I can make a difference by building something to fill the gap.

Conjur OSS Suite Release Managers


As a	Conjur release manager
I want	o know what changes have been made to components since the last suite release
so that	I can decide if enough changes have been made to merit a new release.


As a	Conjur release manager
I want	to know how to create a new release, including any manual steps that are required
so that	I can successfully create a new release without missing any steps.


As a	Conjur release manager
I want	to know the results of automated tests
so that	I can be sure all included components work together as expecteed at the pinned versions.

Conjur Core Downstream Developer


As a	developer on a downstream project that uses Conjur as its core
I want	to know when there are new Conjur OSS suite releases
so that	I can review the changes and update my project to use the latest OSS suite release version of Conjur.


As a	developer on a downstream project that uses Conjur as its core
I want	a machine readable summary of what is included in each OSS suite release
so that	I can build automation around the OSS suite releases as needed.

References to Slack are updated to refer to CyberArk Commons

In cyberark/conjur#1261 it was noted that the Conjur github repo still links to Slack in its README.

Our other public repos need to also be reviewed to ensure that they do not also link to Slack - if they do, they should be updated to refer to CyberArk Commons instead.

There is a standard for documenting security vulnerability reporting

Our public repositories should clearly document what process non-employees should do to report potential security bugs. This could involve:

Including a SECURITY.md file, or similar
Including a snippet in the README or CONTRIBUTING that refers to the security bug policy
Other options?

In this effort, we will define the standard way Conjur Open Source repos should document security vulnerabilities, and we will update the current set of public non-archived repositories to follow this process.

AC:

There is a process defined for documenting how to report security vulnerabilities
Any new repo templates or guidelines are updated with this policy
All existing public non-archived repos follow this process

Copyrights are updated to 2020

The copyrights on our license files in all Conjur-owned repos are updated to

Spike on creating acknowledgements file automatically for Go modules

Given a project that is written in Go and uses Go modules for package management
Then an acknowledgements file (NOTICES.txt) can automatically be created from the go.mod
And when the go.mod is updated
Then the pipeline can auto-detect an update to the acknowledgements is needed
And there is a script to auto-update the acknowledgements file given the new go.mod

Potential tools to leverage to automate this:

https://github.com/nexB/scancode-toolkit
https://github.com/vmware/tern
https://github.com/pivotal/LicenseFinder (currently used by Secretless and the PCF integration)

Non-LGPL repos use the DCO for contributions

Find a way to make in progress / soon to be released work more visible

Improve the workflow to make "in progress" and "merged but not released" issues more visibile in GitHub / to people without ZenHub access

Community README.md clearly describes team roles

The top-level README.md in the community repo should give a clear and detailed introduction to each team (Conjur, Cloud Solutions, Labs, etc.)

Table of contents containing links to other sections of the readme detailing the teams
Full sections that detail information about each group
- "Who we are"-type section
- "What we do"-type section
- Dropdown table with repos owned by the team

CONTRIBUTING.md files in public repos are updated to refer to the community repo for general guidelines

AC:

Every repo in the list below has a basic CONTRIBUTING.md file (template here) - add a file if there isn't one, even if it includes almost no content now
Every CONTRIBUTING.md file links to the community repo "for general contributor information"

Note: as you're adding new contributing files please be sure to update the README to link to the project CONTRIBUTING, and move all contributor focused content from the README to the project CONTRIBUTING.

This means that PRs where you add CONTRIBUTING.md should change two files - CONTRIBUTING and the README. Repos where you update the existing contributing to link to the generic guidelines will just change one file.

Repos:

higher priority repos

lower priority repos

Every Conjur OSS repo has a pull request template

The following projects should be updated to have the same pull request template as the one used in Conjur, here: https://github.com/cyberark/conjur/blob/master/.github/PULL_REQUEST_TEMPLATE.md.

These repos already have a pull request template, please review them and determine whether they can be updated to a format like the Conjur template, or if they need to remain as-is:

cyberark/conjur
cyberark/conjur-template
cyberark/secretless-broker

MsSQL Connection Details supports additional ssl options

NewConnectionDetails has support for SSLOptions, similar to the PG and MySQL adapter.

sslOptions exists as a value in the connectiondetails struct
"sslrootcert", "sslkey", "sslcert" can be specified in the secretless.yml
unit tests exist for the proper handling of these values

Community repo has documentation on the code review process

Finalize how PRs are reviewed (applying to both staff and community members.)
Document this process on conjur.org and in the repo.

The user experience of the OSS suite release manager is defined

GIVEN I am the OSS suite release manager
AND I know what is available to release
AND I have determined what I want to include in the next OSS suite release
AND I know the version of the next OSS suite release
THEN I know the process for creating a new OSS suite release
AND I can follow that process to create a new OSS suite release

AC:

README for release manager is written

wrong place

There is a public community repo with contributor guidelines

AC:

Populate the repo with the contributor license agreement, guidelines on contributing, info on how to get started finding issues, software quality standards and expectations, the process for submitting work and getting it merged
Update existing repositories to refer to the central community repo as appropriate

There is a file descriptors blog post

AC:

The gist published here: https://gist.github.com/doodlesbykumbi/d2f3a90796e0f83792bb47f310da79ca
is edited based on the feedback already given and migrated to WordPress to be published on blogs.conjur.org

PR submission metrics are tracked on a dashboard

Generate dashboard to track:
- Time to first response for a new PR.
- Number of submitted PRs each quarter.
- Average time from submission to approval.
- Top contributors (CyberArk staff and community members.)

Update Puppet

The current Conjur Puppet page lists Zendesk for support (see the support section

The page needs to be updated with current contact information for Conjur support, i.e. the Conjur channel in Discourse here or this github repo's issues section.

Initial metrics on community PRs and issues have been measured

Using a documented manual but repeatable process, metrics are collected on the following:

Time to first response for a new PR.
Number of submitted PRs per month
Average time from submission to approval
Top contributors (CyberArk staff and community members)
Number of issues each month/quarter.
Breakdown by status (e.g. No response, Confirmed, Wishlist, Resolved.) (Note - mapping to these statuses is TBD)
Time to first response.
Average time to final resolution (e.g. Closed, Resolved.)
Top contributors (CyberArk staff and community members.)

Community maturity levels are defined

Aha card: https://cyberark.aha.io/features/AAM-264

The basis for the proposal includes the following:

The original release checklist
@andytinkham's DoD spreadsheet
@brikelly's Slack draft contribution levels

The goal is to define maturity levels for contributions so that we can enable community contributions while continuing to be clear to end users about expected maturity of features in the open source suite of products.

There is a blog post on "lessons from the theater"

AC:

There is a blog post on lessons gleaned from the theatre surrounding healthy team dynamics

All suite release repos have bug and issue templates

This is a follow-up to #26, which (oops) did not include all relevant repos.

Suggested templates:

AC: Add or update feature request and bug templates in the following repos:

Every repo in the Conjur OSS suite has a license header in every source code file

Add a header to the top of all source code files (e.g. .go and .rb files, etc) with:

// Copyright (c) 2020 CyberArk Software Ltd. All rights reserved.
// Use of this source code is governed by an Apache 2.0
// license that can be found in the LICENSE file.

All community team repos have a CODEOWNERS file

The following repos should have a CODEOWNERS file in .github/CODEOWNERS that includes the single line:

* @cyberark/community-and-integrations-team

Create initial Conjur guidelines

AC:
In the Conjur folder, there needs to be:

A README for Conjur Open Source that refers to the content below
A folder for style guides (eg Ruby, Golang, Bash) that is linked to from the README - use existing style guides when possible, and if none exists just create a minimal simple style guide for this directory that liinks to existing content from the pinned style guides in the about-X channels in Slack
A CONTRIBUTING file with:
- Info on looking for CONTRIBUTING.md in other repos
- Info on generic contribution workflow (eg fork, change, PR, etc)
- Special git-flow guidelines that we use, that community users should know about (ie clean commit history, rebase vs merge, etc - can be pulled from our git guide
- General info on typical testing patterns / how to run tests

Community repo has a contribution guide

As with every project, the community repo is open to contributions from the external and internal community.

A CONTRIBUTING.md exists in the top-level directory
Details for internal and external contributors to improve documentation and clarity of community docs structure and content
Details for connecting a project back to the community repo through a README
Common conventions for making a project open for contributions

JDBC Connectivity Tests Exist for Postgres

We verify that connection succeeds with simple queries when connecting to Secretless through JDBC

Add contribution license policy to Conjur guidelines

AC:

The CONTRIBUTING file in the conjur folder of the community repo has guidelines on using the DCO (for MIT / Apache / BSD licensed repos) vs the CLA (can be based on guidelines here)
The community repo includes a copy of the CLA to serve as a central place for projects that use it to refer to it

JDBC Jar is built at runtime for integration tests

The jdbc jar in /tests/util/jdbc currently sits around 4.3 MB, and it would be better practice if we built it for our tests instead of storing the binary in our repository. There are several ways we could approach this, and several steps.

There isn't native support for MsSQL in the JAR, it has to be added along with the official driver from microsoft.
We need to modify the configuration and MANIFEST.md files each time to map the command to the MsSQL driver
Currently, there exists a dependency on eclipse for compiling and exporting. We should try to remove this dependency if possible.
We could introduce building the JAR file as part of our dockerfile build process for the test container

Conjur Golang style guide covers all relevant topics

The Golang Style guide is missing a few categories that are relevant to the work of the Conjur team projects.

Code Coverage - Add target coverage, and example commands to run to get coverage.
Mocking - Determine if we need anything here, e.g. "avoid the use of global variables for mockable interface declarations, and instead propagate mockable interfaces from highest possible level down"
Copyright Notices - Add a sample copyright notice
Logging - Determine what needs to be added here

cyberark / community Goto Github PK

community's People

Contributors

Stargazers

Watchers

Forkers

community's Issues

User Stories

Open Source Users

OSS Suite Component Maintainers

Conjur OSS Contributors

Conjur OSS Suite Release Managers

Conjur Core Downstream Developer

Repos:

higher priority repos

lower priority repos

Recommend Projects

Recommend Topics

Recommend Org