cisagov / .github

Default community health files for cisagov

Community health files for the @cisagov organization ⚕️

For more information, please see the article on creating a default community health file for your organization.

.github's Issues

Update pull request template with pre- and post- approval checklists

💡 Summary

As per discussion in cisagov/kali-packer#57, we'd like to change Checklist to Pre-approval checklist and then also have templated text for post-approval and post-merge.

Motivation

Sometimes, a PR requires work after it's merged. To make it easier to remember to do that work, we would like to include those tasks as checkboxes; however, we also prefer all checkboxes to be checked prior to review to indicate that it's ready.

As per discussion in cisagov/kali-packer#57, we'd like to change Checklist to Pre-approval checklist and then also have templated text for post-approval and post-merge.

Implementation notes

Example, as done by @jsf9k in the linked PR:

## ✅ Pre-approval checklist ##

...

## ✅ Post-approval checklist ##
- [ ] Task

## ✅ Post-merge checklist ##
- [ ] Task

Since this isn't applicable to most PRs, we may also want to make those checklists commented-out by default.

Acceptance criteria

How do we know when this work is done?

• Title of checklist section has changed
• Additional checklist templates have been added

Create a "Code of Conduct" document and handle violation reports

🚀 Feature Proposal

We should consider creating a cisagov-wide "Code of Conduct" document and handling violation reports.

Motivation

When I looked at the cisagov/cool-system repository's Community page, for example, I noticed that there are two unenabled items there. One is a Code of Conduct document and the other is "Repository admins accept content reports".

Pitch

Aside from an OCD-driven desire for completeness, checking off these other items will make cisagov a more mature GitHub organization.

Please Provide me step by step installation process

Step by step installation process

Please suggest me

Motivation and context

Why does this work belong in this project?

This would be useful because...

Implementation notes

Please provide details for implementation, such as:

• an example for how this would be used
• what this would look like
• how this would act
• any related work, including links to related issues

Acceptance criteria

How do we know when this work is done?

• Criterion

none

Troubles with Docker Image

🐛 Summary

Hello, I've been trying to install decider via the docker method and have gotten past the 'db' and 'web' errors, but now I've gotten
to the docker 'compose' is not a docker command. I have v2.17.0 installed and can't seem to have any luck with finding a solution. Thanks.

Modify the PR template after implementation of automatic release generation foo

💡 Summary

@mcdonnnj envisions a future world in which a developer pushes a version tag to a repo, and that in turn kicks off the automatic generation of a release via GitHub Actions. Should we end up implementing such a scheme, we would need to modify the last checkbox in the pull request template to read "Create a tag".

Motivation and context

The creation of this issue is @mcdonnnj's prerequisite for reviewing #47.

Change the first heading in the pull request template to be useful

💡 Summary

Per #28 (review):

One thing I would like to see addressed is the octothorpe-wrapped comment at the very top of the PR template. All that line does is add a pointless horizontal line at the top of the PR, which I find maddening. We can't just remove the octothorpes, since then the linters complain that the first heading in the file isn't a first-level heading. We need to do one of the following:

• Add something to that first-level heading, but I can't think of anything meaningful. The PR title is already handled by the PR web page, so it doesn't make sense to put it there.
• Make the other headings all first-level headings, but that looks terrible.

Motivation and context

As the above remarks, the empty first heading in the pull request template is functionally useless at present.

Consolidate and simplify issue templates

🚀 Feature Proposal

The issue templates we currently have are too specific to purposes that don't generally fit our usage. Let's simplify our issue templates down to:

• Issue template
• Story/Epic template

Motivation

We're working on filing more issues for smaller tasks of work. To do this, let's make the issue process less cumbersome.

Plus, we want folks to file issues when they experience problems, and our Question template tells them to email us.

Example

Refer to templates from cloud.gov for examples:

• cloud-gov Issue template
• cloud-gov Story template

Consider adding an "On Hold" label

🚀 Feature Proposal

We should consider adding an "On Hold" label that is distinct from the "Blocked" label. See the discussion in cisagov/skeleton-generic#63. It may even make sense to create both an "On Hold" label and a more specific "Waiting for Kraken" label.

Motivation

When we are holding back a PR because we are waiting to gather enough PRs for a Kraken release, the PR is not "blocked" per se. There are also other cases where we might put a PR on hold even though it is not actually blocked by anything else, although perhaps the concept of a draft PR covers this case.

The advantage of creating a more specific "Waiting for Kraken" label is that we can easily do a search for it and thus identify all PRs that should be merged when it is time to release the Kraken.

Reconcile PR template and issue template titles

🐛 Summary

The pull request template uses a section title of Motivation and Context, which should be sentence-cased.

The issue template uses a section title of Motivation and these two should match.

To reproduce

Steps to reproduce the behavior:

1. Look at the issue template with your eyeballs
2. Look at the pr template with your eyeballs

Expected behavior

Sentence casing and standardized matching section titles for similar sections.

Standardize org-wide labels

From PR #4, continuing discussion on labels.

We want to standardize on a set of labels org-wide for cisagov.

Individual repos can then add additional labels if needed.

From @jsf9k:

@cisagov/team-ois, I created example labels in this repository. Please have a look and let me know if you think those are good enough to make official here.

From @felddy:

I'd prefer more emojis in the labels... but these are fine.

https://github.blog/2018-02-22-label-improvements-emoji-descriptions-and-more/

entrylvl/platform#54

suricata

May I ask how to judge whether the suricata rule is triggered or not, and what circumstances will cause the suricata rule to fail to take effect? At some point, I found that the suricata event could not be viewed through the event provider in the dashboard.

Rename main branch to develop

Rename the main, protected branch from master to develop like the rest of our repositories and also to move away from historic master/slave terminology.

Update PR template checklists so usage indicates required items

🚀 Feature Proposal

I humbly suggest that in our pull request template we:

1. Change the checklist under the “Types of Changes” section to a bulleted list of suggested types, and leave it up to the PR creator to add/remove change types as needed.
2. Leave the checklist under the “Checklist” section, but add a comment requesting that the PR creator:
   • Remove items that are not appropriate
   • Add items that are appropriate but missing

I am happy to create a PR with these changes, but I wanted to get buy-in/suggestions/alternatives from the group before doing so.

Motivation

Our pull request templates have lists of checkboxes in them, which means that the PRs appear here, for example, with a little checklist icon and the text “X/Y”, where X is the number of checkboxes checked and Y is the total number of checkboxes. In our PR template the intent is that you only check the checkboxes that apply to the PR being created, but GitHub is clearly interpreting the checkboxes as a list of things that must all be done. Hence the little checklist icon and the text, which is misleading because it suggests there is more to do on the pull request when this is not the case.

I feel that the suggested changes in the previous section would allow us to avoid misleading information in PR summaries, and more importantly make the "Types of Changes" and "Checklist" sections more useful and informative. We aren’t in general adding useful items to those lists; draft PRs should have some empty checkboxes under “Checklist”, for example, and sometimes we check no boxes in the "Types of Changes” section because none of the default options apply.

Issue with Ubuntu 20.04 LTS.

🐛 Summary

What's wrong? Please be specific.

To reproduce

Steps to reproduce the behavior:

1. Do this
2. Then this

Expected behavior

What did you expect to happen that didn't?

Any helpful log output or screenshots

Paste the results here:
Same issue with the other user who was using ubuntu 22.04. Can you run this on ubuntu 20.04. Thanks

Add any screenshots of the problem here.

Tag known Tor Node or VPN IP

💡 Summary

Tag known Tor Node or VPN IP
Does anyone know how to tag IP address with known Tor Node or VPN during the ingest?