gitlab.com Open in urlscan Pro
2606:4700:90:0:f22e:fbec:5bed:a9b9  Public Scan

Form analysis
0 forms found in the DOM

Text Content

Skip to content
GitLab
 * Menu
    * Why GitLab
    * Pricing
    * Contact Sales
    * Explore

 * Why GitLab
 * Pricing
 * Contact Sales
 * Explore

 * Sign in
 * Get free trial


PRIMARY NAVIGATION


Search or go to…
Group
 * C
   Clean and iTasks
 * Manage
    * Activity
    * Members
    * Labels

 * Plan
    * Issues
      149
    * Epics
      0
    * Issue boards
    * Epic boards
    * Roadmap
    * Milestones
    * Iterations
    * Wiki

 * Code
    * Merge requests
      18

 * Secure
    * Security dashboard
    * Vulnerability report

 * Deploy
    * Package Registry

 * Operate
    * Terraform modules

 * Analyze
    * Insights
    * Issue analytics




Help
   
 * * Help
   * Support
   * GitLab documentation
   * Compare GitLab plans
   * Community forum
   * Contribute to GitLab
   * Provide feedback
 * * Keyboard shortcuts ?
   * What's new 7


Snippets Groups Projects
 * Clean and iTasks

C


CLEAN AND ITASKS

Libraries and tools for the Clean programming language.

Read more
   
 * Subgroups and projects
 * Shared projects
 * Archived projects
 * Name
    * 
    * 
    * Name
    * Created
    * Updated
    * Stars
      
      
    * 
    * 

 * B
   base
   0 9 1
 * I
   itasks
   0 2 1
 * L
   libraries
   0 32 1
 * ABC Interpreter
   
   An interpreter for the ABC language with Clean bindings to allow
   cross-platform communication of lazy expressions
   
   2
   1 month ago
 * A
   ArgEnv
   
   Mirror of the argenv library to publish to https://clean-lang.org
   
   0
   2 months ago
 * A
   asyncio
   0
   1 day ago
 * B
   base64
   0
   4 months ago
 * C
   Clean Platform
   
   The Clean platform is a collection of multi-platform general purpose
   libraries for Clean.
   
   1
   2 months ago
 * C
   Clean Test
   
   Generic test tools for testing Clean programs
   
   0
   3 weeks ago
 * C
   Clean Test Properties
   
   Generate and run Gast tests from properties defined in Clean definition
   modules
   
   0
   1 week ago
 * C
   clean-lang.org
   
   Source of clean-lang.org
   
   0
   2 weeks ago
 * C
   common-config-repositories
   0
   10 months ago
 * G
   gitlab-profile
   0
   1 month ago
 * G
   GraphCopy
   
   A library to lazily (de)serialize arbitrary expression graphs.
   
   0
   1 month ago
 * G
   G∀ST
   
   The G∀ST testing framework for Clean
   
   0
   1 month ago
 * H
   html
   0
   2 months ago
 * H
   htoclean
   0
   1 year ago
 * iTasks SDK
   
   The iTask framework for developing Task-Oriented Programs.
   
   0
   7 hours ago
 * I
   iTasks-leaflet
   0
   2 weeks ago
 * iTasks-template
   
   This is an iTasks template project which contains an environment to develop
   iTasks applications using docker develop containers.
   
   1
   1 month ago
   

 * Prev
 * 1
 * 2
 * Next



README.md


CONTRIBUTING TO CLEAN AND ITASKS

Thank you for contributing to Clean and iTasks. This document describes how we
work here.

 * Contributing to Clean and iTasks
   * General workflow
   * Git
   * Code Review
     * Code owners
   * Code Style
   * Efficiency
   * Testing
     * Existing Tests
     * New Tests
   * Planning
     * Solving issues
   * Release schedule
     * Release checklist
   * Changelog
     * Which changes require an entry?
     * Entries
     * Headings


GENERAL WORKFLOW

 * The main branch is used for the latest version. Unless the repository is
   older and still has a master branch.
 * Bugs and feature proposals are tracked in the issue tracker.
 * We use feature branches to fix bugs, develop new features, etc. Feature
   branch names should be descriptive.
 * Once code is ready to be merged into main this is done in a merge request.
 * Merge requests are assigned to the person who currently has to work on it.
   This can be a reviewer when the code is ready for review, or somebody else,
   if more work is required before the MR can be merged. Merge requests that are
   not ready for review should also be marked as Drafts.
 * Comment threads are resolved by the person who started them, not the person
   who answers them. This makes sure that everyone has an overview of what
   remains to be done.
 * In preparation of a new major or minor version, a branch pre-x.y is used
   (e.g. pre-2.0). Bug fixes should be done on main or a pre-x.y branch. If bug
   fixes need to be backported to an older version, a branch release-x.y is used
   (e.g. release-1.3).


GIT

 * We prefer git rebase over git merge to bring feature branches up to date with
   main, as this makes git bisect easier.
 * Intermediate commits should compile to make git bisect easier. Use git rebase
   -i to squash commits and clean up your history before making a merge request.


CODE REVIEW

 * Code has to be reviewed and accepted by at least another person, who did not
   contribute a significant amount of code, this person is considered to be the
   reviewer.
 * The reviewer checks whether the changes are in accordance with this document
   and can also bring in other ideas improving the result. The review is
   repeated until the reviewer agrees that the item is done and can be merged.

The reviewer is not required to:

 * Reproduce benchmark results if they seem plausible.
 * Check if all intermediate commits compile.


CODE OWNERS

The maintainer of a package is responsible to assign a reviewer to an MR. In
case the review is expected to take longer than a couple of days, it is
appreciated that the maintainer gives an indicates of when a review is to be
expected.


CODE STYLE

 * The code has to be checked against the code style.
 * The style guide can only be extended once we have automated style checking;
   otherwise this takes too much review time.


EFFICIENCY

Premature optimisation lead to waste of time and can decrease maintainability of
code. There is on the other hand no reason to waste performance by not following
some good practices, requiring minimal effort and not affecting maintainability.
Not choosing the appropriate types beforehand can waste performance and time
when implementations have to be refactored afterwards.

The following points should always hold:

 * All functions and types should have proper strictness annotations.
 * Appropriate choices have been made for types (e.g. Set vs []).
 * The most efficient library functions available should be used (e.g. +++ and
   concat3/4/5 vs concat, lazy vs strict foldl).

If performance is part of the acceptance criteria of an issue, a benchmark
should be done to show that the desired performance is achieved.


TESTING


EXISTING TESTS

 * Existing tests should be adapted if required so that the CI pipeline passes.


NEW TESTS

 * For fixed bugs there should always be a test, which failed before the MR and
   passes after the MR. How thorough the test needs to be depends on the
   probability and impact of failure and can be determined in cooperation with
   the reviewer.
 * In exceptional cases the writing of tests can be delayed to a follow-up
   issue, for example if writing the test is complex or impossible with the
   current framework and/or if the bug has very high priority.
 * For newly added functions, if there are already tests for similar functions
   within the package, tests should be added for the newly added functions as
   well. As an example, consider the functions within Data.Map.


PLANNING


SOLVING ISSUES

In regards to solving issues, the maintainer should indicate whether there is an
intent to spend time on the issue or whether MRs will be accepted.


RELEASE SCHEDULE

The software is released on-demand. Not every change automatically results in a
release. The moment of release is left to the discretion of the maintainers.


RELEASE CHECKLIST

The software is released as a nitrile package.

The changelog entry and versioning used for the repository have to adhere to the
changelog guidelines.

To make a release, do the following, ideally in the same branch with the
relevant code changes you're making:

 * Bump the version in nitrile.yml using the semantic versioning rules.
 * Update CHANGELOG.md.
 * Create a merge request.
 * After merging, create a tag on the main branch with the same name as the
   version number (e.g. 2.0.0). This causes the CI pipeline, when set up
   correctly, to automatically publish this version in the nitrile package
   repository.


CHANGELOG

Each repository contains a file CHANGELOG.md.

At the top of the file there is a heading Unreleased. If you make a change and
want to add a changelog entry, add it here. You may add the Unreleased heading
if there is none.


WHICH CHANGES REQUIRE AN ENTRY?

In general, use common sense, or ask if unsure. Here are some guidelines:

 * New features should always get an entry.
 * Backwards incompatible changes should always get an entry.
 * Bug fixes should always get an entry, unless they fix a bug that has not been
   released yet.
 * Enhancements of existing features should get an entry if they are observable
   for end users.
 * Changes in documentation and refactoring do not need to get an entry.
 * Changes by outside contributors may always get an entry.


ENTRIES

Changes can have different types. The entries should be grouped by type, in this
order:

 * Feature for new user-facing functionality.
 * Enhancement for enhanced functionality without API changes.
 * Change for user-facing changes in functionality.
 * Removed for removed functionality.
 * Fix for fixed bugs.
 * Robustness for changes to catch edge cases.
 * Chore for updates to dependencies and the like.

Each entry should give a short explanation and a link to the corresponding merge
request or commit. Entries may include the name / GitLab handle / email address
of the contributor.

The entry explanation starts with a lower-case letter and ends with a full stop.
For example:

- Feature: add ability to foo bars.


HEADINGS

 * Headings are sorted in descending order.
 * Major versions (x.0.0) and minor versions in the major version 0 (0.x.0)
   should be on heading level 2 (##).
 * Minor versions in non-zero major versions (x.y.0) should be on heading level
   3 (###).
 * Patch versions (x.y.z) should be on heading level 4 (####).
 * There may be a heading ## Unreleased at the top of the file for unreleased
   changes. The level should be the one that the version gets when it is
   released. That is, if there are unreleased changes that require a major
   version update, the level should be ##. If the unreleased changes only
   require a patch update, the level should be ####.