mirrors/flatcar
1
0
Fork 0
mirror of https://github.com/flatcar/Flatcar.git synced 2025-10-25 06:01:06 +02:00
Code Issues Packages Projects Releases Wiki Activity

README: community calls, interop, participation

Browse Source 
Signed-off-by: Thilo Fromm <thilo@kinvolk.io>
This commit is contained in:
Thilo Fromm 2021-05-04 10:55:34 +02:00
parent 184412ac59
commit c08ba9f0bb
3 changed files with 248 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

96
CODE_OF_CONDUCT.md Normal file
View File

@ -0,0 +1,96 @@
# Flatcar Code of Conduct
## Purpose
Flatcar pledges to foster an open and welcoming community, to make our events
and community inclusive to the largest number of contributors and
participants, with the most varied and diverse backgrounds possible. As such,
participants of the Flatcar project pledge to be committed to providing a
friendly, safe and welcoming environment for all, regardless of age, physical
appearance, disability, ethnicity, socioeconomic status, religion (or lack
thereof), level of experience, education, nationality, ethnicity, gender, or
sexual identity and orientation.
This Code of Conduct outlines our expectations for all those who participate in
our projects and community, as well as the consequences for unacceptable
behavior.
We invite all those who participate in our projects to help us create safe and
positive experiences for everyone.
## Open [Source/Culture/Tech] Citizenship
A supplemental goal of this Code of Conduct is to increase open
[source/culture/tech] citizenship by encouraging participants to recognize and
strengthen the relationships between our actions and their effects on our
community.
Communities mirror the societies in which they exist and positive action is
essential to counteract the many forms of inequality and abuses of power that
exist in society.
If you see someone who is making an extra effort to ensure our community is
welcoming, friendly, and encourages all participants to contribute to the
fullest extent, we want to know.
## Expected Behavior
* Participate in an authentic and active way. In doing so, you contribute to the
health and longevity of this community.
* Exercise consideration and respect in your communication and actions.
* Attempt collaboration before conflict.
* Give constructive feedback.
* Refrain from demeaning, discriminatory, or harassing behavior.
* Be mindful of your fellow participants. Alert the project leaders if you
notice violations of this Code of Conduct, even if they seem inconsequential.
## Unacceptable Behavior
Unacceptable behaviors include: intimidating, harassing, trolling, abusive,
discriminatory, derogatory or demeaning communication or actions by any
participant in our community online, at all related projects and in one-on-one
communications carried out in the context of community business.
Harassment includes: harmful or prejudicial verbal or written comments related
to gender, sexual orientation, ethnicity, religion, disability; inappropriate
use of nudity and/or sexual images; inappropriate depictions of violence;
deliberate intimidation, stalking; unwelcome sexual attention.
## Consequences of Unacceptable Behavior
Unacceptable behavior from any community member, including corporate
participants or sponsors and those with decision-making authority, will not be
tolerated. Anyone asked to stop unacceptable behavior is expected to comply
immediately.
If a community member engages in unacceptable behavior, the project maintainers
may take any action they deem appropriate, up to and including a
temporary or permanent ban from participating in the project and community
without warning.
## If You Witness or Are Subject to Unacceptable Behavior
If you are subject to or witness unacceptable behavior, or have any other
concerns, please report it to conduct@flatcar-linux.org.
## Addressing Grievances
If you feel you have been falsely or unfairly accused of violating this Code of
Conduct, you should notify us at conduct@flatcar-linux.org with a concise
description of your grievance. Your grievance will be handled in accordance with
our existing governing policies.
## Scope
We expect all project participants (contributors, paid or otherwise; sponsors;
and others) to abide by this Code of Conduct in all projects as well as in all
communications pertaining to community affairs.
## License and attribution
Flatcar CoC is distributed under CC BY SA 4.0 license.
This CoC is adapted from [Berlin CoC](https://berlincodeofconduct.org/) and
[Packet CoC](https://github.com/packethost/standards/blob/master/CODE_OF_CONDUCT.md).

90
README.md
View File

@ -4,59 +4,89 @@
_Flatcar Container Linux is a fully open source, minimal-footprint, secure by default and always up-to-date Linux distribution for running containers at scale._
## Code of Conduct
Please refer to the Flatcar [Code of Conduct](CODE_OF_CONDUCT.md).
## Releases
See the [project website](https://kinvolk.io/flatcar-container-linux/) for information about [current releases](https://kinvolk.io/flatcar-container-linux/releases/).
See the [project website](https://flatcar-linux.org) for information about [current releases](https://flatcar-linux.org/releases).
## Repositories
## Install and operate Flatcar
Github repositories that comprise Flatcar Container Linux are on the [Kinvolk org and using the Flatcar topic](https://github.com/search?q=org%3Akinvolk+topic%3Aflatcar).
Flatcar Container Linux has a dedicated [documentation site](https://docs.flatcar-linux.org). Some helpful links:
## User Documentation
* [Getting started](http://docs.flatcar-linux.org/installing)
* [Working with clusters](http://docs.flatcar-linux.org/#creating-clusters)
Flatcar Container Linux has a dedicated [documentation site](https://kinvolk.io/docs/flatcar-container-linux/latest/). Some helpful links:
**Does Flatcar run in my environment?** Consult the [interop-matrix](interop-matrix.md).
* [Getting started](https://kinvolk.io/docs/flatcar-container-linux/latest/installing/)
* [Working with clusters](https://kinvolk.io/docs/flatcar-container-linux/latest/#creating-clusters)
* [Migrating from CoreOS Container Linux](https://kinvolk.io/docs/flatcar-container-linux/latest/migrating-from-coreos/)
* [Updating directly from CoreOS Container Linux](https://kinvolk.io/docs/flatcar-container-linux/latest/migrating-from-coreos/update-from-container-linux/)
## Report bugs and request features
Please file a respective [issue](issues) right here in the top-level github project.
For instance, please use the "New Package Request" issue type to [file your request](https://github.com/kinvolk/Flatcar/issues/new/choose). Please see [adding new packages to the Flatcar Linux OS image](adding-new-packages.md) for general guidelines.
## Participate and contribute
For quick questions or for just hanging out with the community please use
* matrix (preferred): [https://app.element.io/#/room/#flatcar:matrix.org](https://app.element.io/#/room/#flatcar:matrix.org)
* IRC (bridged to matrix): #flatcar on freenode, e.g. [https://kiwiirc.com/nextclient/irc.freenode.net/#flatcar](https://kiwiirc.com/nextclient/irc.freenode.net/#flatcar)
If you are thinking of making a contribution, then please engage with the project as early as possible -- by commenting on an existing issue, or creating a new issue, on GitHub. Consider the project’s mission, and how your contribution furthers it.
Making your intent visible early on can be a major factor for getting your work accepted.
Join us in our monthly [community meetings](tree/main/community-meetings) to engage with the Flatcar community interactively, to learn about the project's directions, and to discuss contributions.
Meeting agendas are published in advance. If you have a pressing issue of common interest you'd like discussed, please let us know on Matrix, or simply bring it to the next meeting's Q&A.
For more sizeable agenda items please consider filing a PR to the agenda of the next meeting.
For an introduction to the Flatcar SDK and a walk-through of common developer cases like customising the OS image (e.g. adding or upgrading packages), have a look at our [developer guides](https://docs.flatcar-linux.org/reference/developer-guides/); particularly the [customise images howto](https://docs.flatcar-linux.org/reference/developer-guides/sdk-modifying-flatcar/).
The guides aim to provide a solid base for working with the SDK to help you filing successful PRs to the Flatcar project.
For the general guidelines on making PRs/commits easier to review, please check out the project's [contribution guidelines on git](contributions-git.md).
## Release process
Flatcar Container Linux follows an Alpha-Beta-Stable release process. New features and major version upgrades will enter the Alpha channel for initial testing, then transition to Beta, before landing in Stable.
Note that contrary to features, bug fixes for any release channel will be released to that respective channel directly, i.e. Alpha bug fixes will be included in the next Alpha, Beta fixes will directly go to Beta, and Stable fixes will be released with the next Stable.
Note that unlike features, bug fixes for any release channel will be released to that respective channel directly, i.e. Alpha bug fixes will be included in the next Alpha, Beta fixes will directly go to Beta, and Stable fixes will be released with the next Stable.
## General discussions on the project and its direction
### LTS
For general discussions around Flatcar Container Linux please join our forums (Google groups) for [users](https://groups.google.com/forum/#!forum/flatcar-linux-user) and for [developers](https://groups.google.com/forum/#!forum/flatcar-linux-dev). Please do not use the GitHub project for general discussions. For a quick chat with other users and developers try the `#flatcar` IRC channel on irc.freenode.net.
Some users prefer to avoid the operational impact of frequent version upgrades.
For such users, the Flatcar project provides an "LTS channel".
The LTS channel / branch is based on a "golden Stable" and is maintained for 18 months.
A new LTS is branched from Stable every 12 months, leaving a 6 months window for LTS users to upgrade.
## Code of Conduct
## Project governance
Please refer to the Kinvolk [Code of Conduct](https://github.com/kinvolk/contribution/blob/master/CODE_OF_CONDUCT.md).
Flatcar is a community-driven project, with community members participating through the following forums:
## Contributing to Flatcar Container Linux
* Contributors.
* Flatcar Team.
* Core Working Group.
We encourage community contributions to the Flatcar project! In order to make the contribution process as smooth as possible, please follow the guidelines below.
### Contributors
First, please engage with the development team as early as possible. Let us know (by commenting on an existing issue, or creating a new issue, on GitHub) if you are thinking of making a contribution, so we can align on the best implementation approach and maximize the chances of it being successfully merged. Consider the project’s mission, and how your contribution furthers and is compatible with it.
Every participant of the open source project - bug reporter, feature requester, code contributor - is considered a contributor.
### Commit guidelines
### The Flatcar Team
For the general guidelines on making PRs/commits easier to review, please checkout Kinvolk's [contribution guidelines on git](https://github.com/kinvolk/contribution/tree/master/topics/git.md).
The Flatcar Team comprises contributors with a proven track record of helping the project.
They are members of the Flatcar project on github and are typically responsible for a specific domain within the project, for example:
* Interoperability with a particular environment
* Prioritization and handling of issues
* A specific package or set of packages
* The build / continuous integration process
* Releases
* Community engagement.
### Minor Contributions
### The Core Working Group
Short-term concerns and minor features are covered in the [issue tracker](https://github.com/kinvolk/Flatcar/issues/). When approaching the project please ensure you have searched through / reviewed existing issues and pull requests.
The Core Working Group comprises long term core contributors who have demonstrable impact on the project as a whole.
The Working Group are project administrators/maintainers and ultimately responsible for the project's long-term direction as well as stewarding day-to-day project work.
If an issue or PR you’d like to contribute to is already assigned to someone, please reach out to them to coordinate your work.
## Repositories
If you would like to start contributing to an issue or PR, please assign it to yourself. It is also often helpful to state your intent in a comment on the issue, as well as to announce a rough ETA of your contribution - this helps others to manage their expectations regarding traction and progress.
The repositories are currently part of the Kinvolk org for historical reasons. Flatcar will move to its own github org soon.
### Major Contributions
Major new features are tracked on our [roadmap](https://github.com/orgs/kinvolk/projects/12).
### Requesting new packages
Please see [adding new packages to the Flatcar Linux OS image](adding-new-packages.md) for general guidelines, and please use the "New Package Request" issue type to [file your request](https://github.com/kinvolk/Flatcar/issues/new/choose).
Meanwhile, github repositories that comprise Flatcar Container Linux can be found via the [Flatcar topic](https://github.com/search?q=org%3Akinvolk+topic%3Aflatcar).

92
contributions-git.md Normal file
View File

@ -0,0 +1,92 @@
# Git and Github
This section has the guidelines we use to keep consistency across our different
Git repositories and Github projects.
## Start coding
If you're looking where to start, you can check the issues with the
`good first issue` label. Other labels will be used that may be more related to
the projects themselves, so don't hesitate to get in touch with the developers
if you need more guidance on how to start contributing to our projects.
## Proposing new features
If you want to propose a new feature (e.g adding a package) or do a big change
in the architecture it is highly recommended to open an issue first to discuss
it with the community.
## Authoring PRs
These are general guidelines for making PRs/commits easier to review:
* Commits should be atomic and self-contained. Divide logically separate changes
to separate commits. This principle is best explained in the the Linux Kernel
[submitting patches][linux-sep-changes] guide.
* Commit messages should explain the intention, _why_ something is done. This,
too, is best explained in [this section][linux-desc-changes] from the Linux
Kernel patch submission guide.
* Commit titles (the first line in a commit) should be meaningful and describe
_what_ the commit does.
* Don't add code you will change in a later commit (it makes it pointless to
review that commit), nor create a commit to add code an earlier commit should
have added. Consider squashing the relevant commits instead.
* It's not important to retain your development history when contributing a
change. Use `git rebase` to squash and order commits in a way that makes them easy to
review. Keep the final, well-structured commits and not your development history
that led to the final state.
* Consider reviewing the changes yourself before opening a PR. It is likely
you will catch errors when looking at your code critically and thus save the
reviewers (and yourself) time.
* Use the PR's description as a "cover letter" and give the context you think
reviewers might need. Use the PR's description to explain why you are
proposing the change, give an overview, raise questions about yet-unresolved
issues in your PR, list TODO items etc.
PRs which follow these rules are easier to review and merge.
[linux-sep-changes]: https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#separate-your-changes
[linux-desc-changes]: https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#describe-your-changes
### Commit Format
```
<area>: <description of changes>
Detailed information about the commit message goes here
```
Both the title and the body of the commit message shoud not exceed
72 characters in length. i.e. Please keep the title length under 72
characters, and the wrap the body of the message at 72 characters.
Separate the title and the body by 1 empty line.
Use the [imperative mood](https://chris.beams.io/posts/git-commit/#imperative)
for the title, and don't add a period at the end.
For the commit's message body, a period should come at the end of each
sentence (unless the line is not a regular sentence, e.g. code).
Here is an example of commit messages:
Good:
```
app-shells/bash: update ebuild to 5.3
Gentoo upstream has unmasked bash 5.3 and declared it stable.
This change updates the component to use the latest upstream ebuild.
```
Bad:
```
Update bash
Updated bash to the latest one.
```