witteborn / githubboilerplate Goto Github PK

Detailed Description

The security issue template is now redundant because of the security.md file.
I also found a copy and paste issue in the template description for "Improvements"

Tasks

• Fix Improvement template description
• Remove security template

Detailed Description

There should be a way to inform maintainers and deploy/migrate updates to repositories which use this as their template.

Context

The base/template repository might update over time. It would be very time-consuming updating all repositories who use this template manually. Doing it manually might be impossible because there are very limited possibilities to know which repositories use the template.
They might have made some changes, which they should be able to keep by merging the changes.

Further Information

Update template - pabio
Update template - karlvr
Update template - solvaholic

Detailed Description

A SECURITY file gives instructions for how to report a security vulnerability in your project.

Tasks

• Create document
• Add reference to README.md

Context

I found out about this here.

Possible Implementation

• Checkout other repositories

Detailed Description

Transferring labels from the template repository to a new one should be as easy as triggering a workflow.

Context

GitHub doesn't provide a way to transfer labels, even by using project templates.
Manually writing down all the labels for each project is very tedious, but not doing so might break certain workflows like the GitReleaseManager for example who is expecting a set of labels.

Possible Implementation

This repository should implement the issue-label-manager-action.

Tasks

• Write down labels in json as described
• Implement workflow

Further Information

issue-label-manager-action

Detailed Description

There should be a GitHub Actions workflow which checks if the pr title is in compliance with the contribution guidelines.

Context

There are several GitHub Actions which help to improve the review process.
Part of each review is the compliance of the contribution guidelines.
They define, among other things, a naming schema for pull requests.

Possible Implementation

Checkout the repository linked below.

Further Information

The repo

Detailed Description

This project should contain a good and catchy description

Context

This will help people find this project and also immediately understand how it works.

Detailed Description

Categorize issues into milestone for easier project management.
This will also show how the release draft workflow is functioning.

A roadmap file might also be useful and practical to have in a project template.

Tasks

• Create milestone
• Categorize issues
• Create roadmap

Detailed Description

There should be automated spelling and grammar correction on documents like the README.
This would not only reduce the amount of typo PRs/Issues, but also increase the quality of these documents.

I don't think the content written in the PR or commit messages should be checked on because this might prevent people from contributing if the first thing they experience from the project is a bot which tells them they spelled something wrong.

Tasks

• Find tools
• Decide for a tool
• Implement certain tool

Context

Spelling and grammatical errors can occur all the time, especially with non-native speakers.

Possible Implementation

As part of the review process on each pull request, the spelling/grammar correction tool could analyze the documents named above. This can easily be done with a GitHub actions workflow.

Further Information

• GitHub Spellcheck Action
• Run LanguageTool with reviewdog
• GitHub Action: Run shellcheck with reviewdog
• GitHub Action: Run hadolint with reviewdog
• LanguageTool
• TeXtidote Action

Checklist

• The bug has not been reported before or it is reoccurring in a newer version

Detailed Description

GRM cannot find its configuration file and therefore crashes when trying to create a release.

The expected behavior would be that GRM can find its configuration and act accordingly.
The actual behavior is that it cannot find its configuration and therefore tries to work with the default configuration which results in an error.

Steps to Reproduce

Actions --> Create Release manager --> Run Workflow
Choose the hotfix branch in this case

Related Branch or Version

Branch: All branches
Version: 1.0.0

Further Information

Default configuration
GitReleaseManager Documentation

Detailed Description / Context

The project should contain a code of conduct to define standards for how to engage in this community.

Tasks

• Create document
• Add additional writing (if required)
• Add reference to README.md

Possible Implementation

• Using a template with: New File --> CODE_OF_CONDUCT and then choose a template and fill the form.
• Checkout Cake Contribution Guidelines and look at how they did it.
• A mix of the above

Further information

• Github Documentation

Detailed Description

A SUPPORT file lets people know about ways to get help with your project.

Tasks

• Create document
• Add reference to README.md

Context

I found out about this here.

Possible Implementation

• Checkout other repositories

Describe

As descriped in the workflow file itself the currently used method should be replaced with a more robust and more secure alternative

Tasks

• Replace Create a PR
• Find a more robust way for file comparison

Related Workflow

sync-from-template.yml

Detailed Description

A description helps caregivers and contributors find and categorize issues.
The following labels do not have a description:

Tasks

• Security
• Breaking change

Detailed Description

I like the simplicity of just using the "use template" feature of GitHub itself.
But sometimes setting up a project requires a few more tweaks than can be provided.

I am open for ideas but as an MVP there could be a simple cli tool which asks a few questions and creates a repository based on that.
This can be enhanced later down the line.

Possible implementation features (these are just my ideas right now)

• Setup a cli project for the feature flags
• implements options
  • just everything (all/full)
  • funding
  • pr templates
  • issue templates
  • gitversion
  • license
  • code of conduct
  • contributing
  • readme (and logo)
  • security
  • issue labels
  • workflows
    • sync from upstream
    • release draft
      • GitReleaseManager
      • Basic GitHub implementation
    • Add support for more non spoken languages
      • JS
      • TS
      • Rust
        • cargo fmt (maybe others could also use a formatter later)
      • C#
        • Cake
        • Nuke
        • Dotnet
      • Java
      • LaTeX
      • Python

Further Information

I might split this issue up into more smaller tasks or reduce the scope of what should be done later. For now these are just a bunch of ideas

Detailed Description

The README file for this project is empty. Projects will use this file as a template.
It should be designed to be used this way, but also inform about this project.

Context

A README file is the first thing people see in this project, so the design and structure is very important.

Possible Implementation

The project already contains a README.md, maybe this one could be improved.

• Checkout their README: React Boilerplate for more ideas

Detailed Description

The project already has a template for pull requests, but this has not always proved useful and therefore needs to be overhauled.

Detailed Description

Tasks

• Task

Context

Detailed Description

Issue templates should be created for the following areas:

Tasks

• Bug
• Feature
• Improvement
• Documentation
• Operative
• Actions
• Security
• Question

Context

Contributing to a project should be done as easily as possible. This includes good task management. Even for developers, writing tasks or issues is not always easy. To ensure that these have a uniform structure and quality, templates should be created. This way, the contributor only has to concentrate on the content, less information is forgotten and the quality of error descriptions and the like increases.

Detailed Description

This project should implement the super linter action
To see all the benefits this tool provides please checkout the context section of this issue.

Context

Things the super linter does extracted from their readme:

The end goal of this tool:

• Prevent broken code from being uploaded to the default branch (Usually master or main)
• Help establish coding best practices across multiple languages
• Build guidelines for code layout and format
• Automate the process to help streamline code reviews

Detailed Description / Context

Contribution guideline should help not only to have a more professional appearance but also contains very useful information for people who are still unfamiliar with the project. It also helps to have a consistent format in the project structure.

Tasks

• Create document
• Add reference to README.md

Possible Implementation

• Checkout Cake Contribution Guidelines

Further information

• Github Documentation

Detailed Description

A FUNDING file displays a sponsor button in your repository to increase the visibility of funding options for your open source project.

Tasks

• Create document
• Add reference to README.md

Context

I found out about this here.

Possible Implementation

• Checkout other repositories

Further information

• Displaying a sponsor button in your repository
• Github Sponsors

Detailed Description

The concept of a wiki is not common and should be more present in open source projects.
This project could help providing the basic boilerplate needed for a github wiki.

Context

The concept of a wiki is not widespread and should be more prevalent in open source projects.
Projects increase in scope and complexity. Therefore, project documentation can help both new and long-time contributors remember how things work and how certain things are done.

Further information

• Github Documentation

Detailed Description

The labels in the configuration file are not up to date.
There are also many new things that can be configured now.

If they are not fixed, this can and likely will lead to errors in the draft release generated by the workflow.

Further information

GitReleaseManager