sokuteihq / sokutei Goto Github PK

Brief

By providing issue templates, we can make the interaction between the community and the developers a more streamlined experience. Thus, we should create templates for the most important issue types.

Task

Create appropriate issue templates for the most important expected issue types.

Resources

Use the following resources as guidelines:

• GitHub Issue Templates
• Gatsby.js Issue Template

The ensure_counter function is a counter creator but as opposed to other creators, this function does not generate an error if called multiple times with the same parameter. This way, we can create counters in the benchmarked function without having to create them before the call.

Brief

Publishing a new version of the library should be an automated process, making use of GitHub Actions.

Task

Create a GitHub Actions Workflow which

• runs on a new tag push,
• and creates a new release with the library header as an attached artifact.

Resources

Primers on CI/CD:

• Martin Fowler: Continuous Integration,
• What is CI/CD?,
• 500 Lines or Less: CI.

Make sure to check out the following links if you're not familiar with GitHub Actions yet:

• An Introduction to GitHub Actions,
• GitHub Actions Documentation,
• Starter Workflows,
• GitHub Actions Toolkit.

Brief

To increase community engagement and decrease the number of question issues, we should create a Discord server. This would come with the added benefit of people getting answers quicker as opposed to the GitHub Issues section.

Task

Create a Discord server for sokutei, where

• people can discuss topics closely and loosely related to sokutei,
• questions can be asked, if one has a problem with sokutei,
• aspiring contributors can get guidance.

The following Discord servers can be used as examples:

• Gatsby.js Discord,
• underdocs Discord.

Brief

To make the project more approachable for others, we should create a CONTRIBUTING.md document.

Task

Create a CONTRIBUTING.md document which contains the following information:

• The kind of accepted contributions and how to submit them.
• Coding style, branching guide, commit message style guide.
• How to build and test the project.

Resources

The following links contain useful guidance:

• Setting Guidelines for Repository Contributors,
• Writing Your Contributing Guidelines.

A recently created one:

• underdocs Contributing Guidelines.

Brief

People can't safely make use of our code without a license. Thus, it's crucial to choose one.

Task

Choose and add a LICENSE to the project.

Resources

• Choosing a License.

Brief

The three counter types featured by Sokutei are as follows: integer, float and interval. Out of these three, integer seems like the easiest one, so it's a great first issue to create the foundations of the library.

Thus, this epic has two roles:

• actually implement integer counters,
• create the basic machinery into which other counter types can be integrated.

Functional Requirements

Clients should be able to

• create new integer counters with custom string names,
• alter the values stored by the counters (by counter names),
• retrieve the values stored by the counters (by counter names),
• change in compile time the underlying type of the integer counters.

Creation

Example API:

sokutei_create_integer_counter("some counter");

This call/macro should create a new integer counter with the name some counter.

Parameters

• counter name
  • Clients should be able to pass any valid string as a counter name. Only the length of the string should be restricted.

Error Handling

• A counter already exists with the same name.
  • We should provide a custom hook for users to handle this error.

Alteration

Example API:

sokutei_alter_integer_counter("some counter", -10);

This call/macro should alter the value stored by some counter by -10.

Parameters

• counter name
  • The name of the counter to alter.
• value
  • The alteration value.

Error Handling

• There is no counter with the specified name.
  • We should provide a custom hook for users to handle this error.
• There is a counter with the specified name but it's not an integer counter.
  • We should provide a custom hook for users to handle this error.
• The value provided does not match the counter type.
  • We can't really do anything in this case. This will be either a compile time error or a surprising runtime case.

Retrieval

Example API:

sokutei_get_integer_counter("some counter")

Parameters

• counter name
  • The name of the counter to alter.

Error Handling

• There is no counter with the specified name.
  • We should provide a custom hook for users to handle this error.
• There is a counter with the specified name but it's not an integer counter.
  • We should provide a custom hook for users to handle this error.

Changing Underlying Type

Example API:

#define SOKUTEI_INTEGER_COUNTER_TYPE int

By defining this macro, users can change the underlying type of integer counters (the type in which the counter value is stored). A default value should be provided if the user does not define this macro.

Implementational Considerations

Open for New Types

Implementation should be done so that other counter types can be easily added.

No Dynamic Allocation

The implementation should not make use of dynamic memory allocations.

No Header Includes

The implementation should not include any headers. Not even ones from the standard library.

Brief

Navigating the repo is much easier if there is a pre-defined and consistently applied branch naming strategy.

Task

• Decide on a branch naming strategy. For example:

  #<issue-number>-<hyphenated-issue-name>
  

  which gives stuff like this:

  #11-enforce-consistent-branch-naming-strategy
  

• Document the strategy in the CONTRIBUTING.md file (#13).
• Enforce the strategy using a git hook
  • Example for the above strategy: underdocs

Brief

As of now, we have no testing process set up. However, we would like to have an extensive test coverage of the library.

Task

Set up test builds with CMake and write an example test using https://github.com/silentbicycle/greatest

Notes

Feel free to copy greatest.h into the repository source tree.

Brief

Tests should run on every integration so that we can catch bugs early. Therefore, create a GitHub Actions Workflow running the tests.

Task

Create a GitHub Actions workflow which

• runs on
  • push to the master branch,
  • PR to the master branch,
• executes the tests.

Resources

Primers on CI/CD:

• Martin Fowler: Continuous Integration,
• What is CI/CD?,
• 500 Lines or Less: CI.

Make sure to check out the following links if you're not familiar with GitHub Actions yet:

• An Introduction to GitHub Actions,
• GitHub Actions Documentation,
• Starter Workflows,
• GitHub Actions Toolkit,

Dependencies

Depends on #21

Brief

As part of the increased open source friendliness initiative, we should add a Code of Conduct to the project.

Task

Add a CODE_OF_CONDUCT.md to the project with appropriate contents.

A great "drop-in" Code of Conduct is the one provided by the Contributor Covenant.

Brief

Navigating the commit and version history is much easier if commit messages have a pre-defined style.

Task

• Examine the Conventional Commits recommendation.
• Document the commit message style in the CONTRIBUTING.md file (#13).
• Enforce commit message conventions using a git hook.
  • Example using Husky: underdocs package.json