eiffel-community / community Goto Github PK

I changed the template to follow the Project Lifecycle Process.
Note that we do not need the repositories yet. We are aiming at setting up ETOS open source at the end of this month.
I can also create the repositories myself, I think. We just need approval :)

Name

ETOS

Description

ETOS is an abbreviation of Eiffel Test Orchestration System. It is a modern driver of test automation and it communicates using the Eiffel protocol.
It is a good entry-point in building a full-scale Eiffel solution at a company and our company is using it internally for executing test automation in a structured way.

The main selling point of ETOS is the fact that it separates the concerns of test automation in to three distinct groups. The System/Tools engineers, the test automation engineers and the testers.
System/Tools engineers make sure that the system is up and running and that all the infrastructure around ETOS is running as it should.
Test automation engineers create the recipes that define how to execute a given test or test suite.
Testers decide which recipes need to execute within the CI/CD pipeline.

Note that a person or entity may, of course, be responsible for more than one of these roles.

Project license

ETOS will be licensed the same as every other project within the Eiffel community; under Apache 2.0.

Name of initial maintainers

Anders Josephson [email protected]
Fredrik Fristedt [email protected]
Tobias Persson [email protected]

Infrastructure needs such as Git repositories

ETOS is a large project with many microservices.
For starters we will need these repositories:

• etos
• etos-suite-starter
• etos-suite-runner
• etos-test-runner
• etos-test-runner-containers
• etos-api
• etos-environment-provider
• etos-library
• etos-client

We have chosen the prefix "etos-" for these projects instead of "eiffel-" as it makes it clearer that it's part of the "ETOS" project.
This should be clarified in the "PROJECTS.md" file that "ETOS = Eiffel Test Orchestration System". It should also be clarified in each individual repository.

In terms of extra infrastructure we would need to publish Docker containers as well as Helm charts for these. Not sure if that should be provided by the Eiffel community or not.

Description

We should provide an issue template for proposing new projects (and perhaps also other project lifecycle changes). The current template from https://github.com/eiffel-community/.github/tree/master/.github doesn't apply in those cases.

Motivation

The current sole issue template isn't a good fit for a relatively common use case and one that people seldom embark on, i.e. there's a good chance that every time a user proposes a new project confusion will arise.

Exemplification

N/A

Benefits

Providing a good template based on PROJECT_LIFECYCLE.md is obviously beneficial for users and maintainers alike.

Possible Drawbacks

We might also have to migrate aforementioned legacy template (https://github.com/eiffel-community/.github/blob/master/.github/ISSUE_TEMPLATE.md) to the new-style format that supports multiple templates. Well, that's perhaps not really a drawback but something that should be done anyway.

Description

Eiffel Community is in the process of documenting Security/Vulnerability Reporting and Response Process. As part of this process, a mail address to report security/vulnerability issues is required so the users can do that in a secure manner.

Motivation

It is important to receive and handle security/vulnerability issues properly so the reports are available only to Eiffel Community Members who are responsible for handling such issues.

Exemplification

N/A

Benefits

Security/vulnerability issues are reported to and known by the Eiffel Community Members and not by public until they are fixed and disclosed.

Possible Drawbacks

N/A

Description and Motivation

The community has voiced change proposals for the CODE_OF_CONDUCT.md and CONTRIBUTING.md documents present in every repository.

This is an attempt to gather all those comments and update the files accordingly when a consensus has been reached so that we have new and improved versions of these documents.

Then we need to propagate these new changes to every Eiffel repository in some way. This can be done either by just updating the default files in .github or by replacing the files in every repository. This is essential so that different repositories do not have different versions of the same documents.

Possible Drawbacks

We might run the risk of creating diverging documents in the community. Care has to be made so that all changes are propagated to all repositories.

As an Eiffel Community Member, I would like the members of Eiffel Technical Committee for the bootstrap phase identified so that I can get guidance from the committee with regards to the project.

Name

Eiffel event repository API

Description

An API against event repositories that exposes the endpoints required by REMRem and other tools for the Eiffel community.
This API will expose the endpoints described in the swagger schema here: eiffel-community/eiffel-event-repository#11

This will be an empty project to start (just some scaffolding and boilerplate) in order to develop this fully open source within the Eiffel community. This means that anyone is welcome to help out.
It will be written in Go and, to start with, use MongoDB as the database since it's what we are using with the Eiffel GraphQL API.
Nothing stops people from implementing more database drivers.

Project license

Will be licensed the same as every other project within the Eiffel community; under Apache 2.0.

Name of initial maintainers

Tobias Persson [email protected]
Magnus Bäck [email protected]

Infrastructure needs such as Git repositories

Git repository: eiffel-event-repository-api

As an Eiffel Community Member, I would like the project lifecycle documented so that I know how to propose new projects, the lifecycle and their maturity levels.

Description

Too long and complicated GOVERNANCE documents may scare away potential contributor, time to have a fresh look at ours and - if need be - propose updates

Motivation

So joining the community is an easier and welcoming thing

Exemplification

N/A

Benefits

So joining the community is an easier and welcoming thing

Possible Drawbacks

Description

As discussed on Slack there are several eiffel-community repositories that contain one or more dockerfiles but only a small number of them have publicly available images (https://hub.docker.com/u/eiffelericsson). We should set up automated builds of all our images and have them push to e.g. Docker Hub after every merged PR. There are at least a few ways to accomplish this:

• Use Docker Hub's automated builds feature.
• Use the Jenkins instance owned by the Nordix foundation for building and pushing images to Docker Hub (or some other public registry).
• Use a docker/build-action GitHub action to build and push images to Docker Hub (or some other public registry).

I have set up an eiffelcommunity Docker Hub organization. The free tier only allows three users, but with sufficient automation that might go a long way. Otherwise prices start at $25/mo for five users.

Motivation

Public and up to date Docker images would be useful to many people. It would also reduce the risk of mistakes and reduce the burden on maintainers (who'd otherwise have to build and push images) and community maintainers (who'd have to administer push permissions).

Exemplification

After merging a PR I'd love to just be able to flip the image tag in our local deployment YAML files and deploy instead of having to sync the git in question, build, and push to a local registry, or spend time on automating this task locally on our site.

Benefits

See Motivation, above.

Possible Drawbacks

It would be another cloud-based entity owned and administered by the Eiffel community. Right now we only have the GitHub repositories.

Description

Eiffel Community will have regular meetings where contributors will discuss various topics such as bootstrapping Eiffel Community processes and procedures. It is important that community makes meeting agenda and notes publicly available and editable by the everyone taking part in Eiffel Community.

HackMD.io is an open source tool that enables collaborative editing. By enabling HackMD.io for Eiffel Community, the community can keep their notes on it and also sync them back to corresponding repositories.

Motivation

Enable Eiffel Community meeting agenda and notes to be available and editable publicly.

Exemplification

Various communities use HackMD.io for keeping notes such as Continuous Delivery Foundation.

Benefits

Increased collaboration and visibility.

Possible Drawbacks

N/A

Description

There is an ongoing debate and various initiatives are ongoing in order to improve the language used within open source.
Various communities and organisations are working on replacing the terms they use with more inclusive terms.

Here is the page where Linux Foundation Networking is collecting such initiatives: https://wiki.lfnetworking.org/display/LN/Inclusive+Language+Initiative

And another reference regarding Jenkins: https://www.cloudbees.com/words-have-power-updating-industry-terms

Eiffel Community will be impacted by this change one way or another so it is important for us to attempt improving the language used across the projects within Eiffel Community and look for impacts that may be caused by other communities and organisations we interface.

One example of such organisation is GitHub. GitHub plans to switch from master to main for naming the default branch.
It seems this is already implemented for newly created repositories and existing repositories may be impacted as well.

More information about GitHub plans to do is available on: https://github.com/github/renaming

Motivation

Switch to using inclusive language and analyse & prepare for potential impacts.

Exemplification

Linux Foundation Networking: https://wiki.lfnetworking.org/display/LN/Inclusive+Language+Initiative
Jenkins: https://www.cloudbees.com/words-have-power-updating-industry-terms
GitHub: https://github.com/github/renaming

Benefits

Use of inclusive language and being prepared to potential impacts.
Eiffel Community will need to analyse the terms used in the code base and identify if improvements are necessary.
Apart from that, the existing CI/CD pipelines may be impacted by the changes introduced by other communities and organisations so the work that's done by Eiffel Community will limit such impacts.

Possible Drawbacks

Impacts on codebase and existing CI/CD pipelines.

As an Eiffel Community Member, I would like the governance documented so that I know the open source methodology followed by the project, the actors, roles and the decision making process.

Code style and test coverage applications is used to ensure that all commits follow a decided code standard and that code is of good enough quality. Github has several such applications in their Marketplace, some is free to use on open source projects while others have a monthly fee.

The Eiffel community should approve and give recommendations for which of those applications that could be used in the repositories. To help the community to take such a decision we have compared several free alternatives and can after that propose a suggestion for the decision to take. Once the decision has been taken those applications should be opened to be used as a 3rd party application to all repositories in the Eiffel community.

The candidates is currently:

• Coveralls
• Codebeat
• Code Factor
• Codacy

The recommendation is to approve the use of Coveralls and Codacy since they may be used to complement each other, where Coveralls is to be used to ensure test coverage and Codacy is to be used for code quality check. None of the applications seems to work well with both test coverage and code quality checks, although Codacy as the only application that should be able to handle both.

Attached to this issue is a document with more detail description, pros and cons with the applications.
github code style comparisons.xlsx

Name

Go package for Eiffel events (aka go-eiffel)

Description

When working with Eiffel events it's beneficial to have them available as formal types in the language you're using. This is especially true for typed languages like Java and Go where working with untyped maps quickly becomes inconvenient. This project will provide a Go package with types (mostly structs) that mirror the JSON schemas in the Eiffel specification and code to simplify serialization and deserialization of such values to and from JSON.

The Go code may be generated in whole or in part from the JSON schemas, either with existing third-party tools or with a bespoke tool included in the package.

Project license

Apache Open Source License 2.0

Name of initial maintainers

Magnus Bäck (@magnusbaeck)
Tobias Persson (@t-persson)
Felix Hall (TBD)
Jonas Alfredsson (@JonasAlfredsson)

Infrastructure needs

Git repository: go-eiffel

One could argue that this name isn't descriptive enough, but keep in mind that the SCM repository URL is used as the import name in Go, so choosing a very long and descriptive name will come at a cost in the source code (or require that users always alias the imported package).

Description

Eiffel Community established and documented security/vulnerability reporting and response process.
This process is overseen by Eiffel Community Security Officers who are appointed by Eiffel Technical Committee.
The role, responsibilities, and term of the Security officers together with the appointed community members must be documented in governance.

Motivation

The role, its responsibilities, the appointed community members and their term documented in governance for transparency.

Exemplification

This is a common practice within open source communities.

Benefits

Increased transparency and communication.

Possible Drawbacks

N/A

Description

There is no common guidelines about how to support the version handling and how long we should support the deprecated endpoints. This issue is create to make a guidelines available across the community so that we adhere the same across different repositories

Motivation

We have different repositories adhering to different ways w.r.t version handling of endpoints, so this can be brought in as a common way to support them.

Exemplification

Benefits

Possible Drawbacks

Description

The GOVERNANCE.md document do not reflect the actual way of working with maintainers and CODEOWNERS file. We do not use the CODEOWNERS file to keep track of the repository maintainers, but instead use GitHub's built in functionality of maintainer lists. We need to update the GOVERNANCE.md document to reflect this.

Motivation

See above.

Exemplification

Benefits

We get a less confusing process of adding maintainers, and a more clearly defined election process (since only maintainers are allowed to be nominated to the Technical Community.

Possible Drawbacks

As an Eiffel Community Member, I would like the community vision, mission and goals are documented so that I can contribute to Eiffel community to fulfill them.

Description

I would like to have a howto guide about creating a new repository/including an existing repository into the Eiffel community.

We have the https://github.com/eiffel-community/eiffel-repository-template and it contains a short checklist of repository specific details. But a general guide in this community repository would be appreciated (since it will probably be easier to find).

Motivation

Good to have a written down process to refer people to when introducing new repositories into the Eiffel community.

Exemplification

The howto guide could contain details on who to contact and of course references to the template repository.

Benefits

See motivation.

Possible Drawbacks

As an Eiffel Community Member, I would like the contribution guidelines documented so that I know how to contribute.

Description

There is an idea to bring up a Kubernetes Cluster for Eiffel Community in order to use it as part of Eiffel CI/CD to deploy Eiffel components for testing purposes. In addition to using it for CI/CD this could be a step toward bringing a reference Eiffel deployment as well.

Motivation

Eiffel Community does not have extensive testing at the moment.
This will allow community to explore ways to extend the test scope for Eiffel Components as well as open up further opportunities to deploy Eiffel for real in open source.

Exemplification

Many communities have such environments to run tests or use for production purposes.

Benefits

This will allow community to explore ways to extend the test scope for Eiffel Components as well as open up further opportunities to deploy Eiffel for real in open source.

Possible Drawbacks

This will require Eiffel Community members to put some time on maintaining the Kubernetes Cluster and adjust Eiffel CI/CD for deploying Eiffel components on it.

Description

New repo creation howto document is outdated and does not contain information about when the described process could be followed.

Based on the work Eiffel BTC did, the creation of new projects are done following the process described in project lifecycle document so this commit adds a note together with the links to corresponding documentation in howto document.

Motivation

Community adapted a new process for project lifecycle so this commit makes existing documentation inline with the process.

Exemplification

N/A

Benefits

Updated instructions.

Possible Drawbacks

None

As an Eiffel Technical Committee member, I would like the chair of the Technical Committee for the Bootstrap Phase elected so that the committee can be assisted to perform its duties.

Description

The members of Bootstrap Technical Committee (BTC) and chair have been appointed during the Technical Committee (TC) meeting on September 14th. The list of BTC members and chair shall be documented in governance according to action item.

Motivation

List members and chair of the BTC for increased visibility and transparency.

Exemplification

https://github.com/spinnaker/governance/tree/master/committee-technical-oversight#members
https://github.com/tektoncd/community/blob/master/governance.md#tekton-bootstrap-governance

Benefits

Increased visibility and transparency.

Possible Drawbacks

N/A

Description

Eiffel Community is an active community and there are times certain requests require to be handled. Some of the example requests are

• adding/inviting people to Eiffel GitHub Organisation
• creating new repositories
• creating new maintainers group
• adjusting permissions of individuals on certain repositories

These requests are currently taken care of by few volunteers from the community. It is important the community contributes to managing Eiffel Organisation so the workload on individuals who are currently working with community support can be reduced.

In order for this to happen, it is important to

• list and document types of activities that are currently being handled by volunteers from the community
• determine the approval requirements (eg. approval of 1 TC members is sufficient for a change to pass for infra changes)
• appoint individuals as Eiffel organisation contacts

Motivation

Identify and document community support process and contacts who look after support issues.

Exemplification

Communities generally have list of interested/appointed people looking after support issues which Eiffel Community could adapt as well.

Benefits

Increased visibility on how community support works and reduced workload on the current volunteers.

Possible Drawbacks

N/A

Description

Something to signal the level of maturity of tools is needed. As it is now we have a mix of (more or less) abandoned repositories, experimental code and production grade code.

This issue is about applying sandbox badge as described in project lifecycle document.

Motivation

Without this distinction it's more difficult than it should be for newcomers to get started. The overall impression of Eiffel suffers.

Exemplification

When users deploying RemRem,, they ran into a number of unexpected problems. Refer to the issues filed in eiffel-remrem-generate and eiffel-remrem-publish.

Benefits

Having information about the status of projects upfront makes it easier for potential users to estimate the effort needed for deployment.

Possible Drawbacks

If we're not careful it might give the wrong impression and make users hesitant to try out, and contribute to, the development of new tools.

Description

Describe how to handle dependencies between repositories.

Currently Eiffel Intelligence Frontend is dependent on Eiffel Intelligence . If the front-end requires a feature in the back-end there is no point in releasing or building Docker container for the front-end until the back-end has the functionality merged.

In ETOS on the other hand there is a wish to build the containers on every merge.

Motivation

Need a unified way of handling dependencies between repositories.

Exemplification

See description

Benefits

Avoiding unusable releases and docker containers

Possible Drawbacks

N/A

Description

Eiffel Community will move to a meritocratic Technical Committee during 2021Q1.

It is necessary to document Election Process together with roles, rules, and exceptions so the community is aware of the election process adopted by the community.

Motivation

Election process, including roles, rules, and exceptions documented so the community is aware of how they can contribute to the governance of Eiffel by taking part in elections.

Exemplification

https://www.jenkins.io/project/board-election-process/
https://wiki.opendaylight.org/display/ODL/TSC+Election+Process

Benefits

Election process, including roles, rules, and exceptions documented.

Possible Drawbacks

N/A

As an Eiffel Community Member, I would like the code of conduct documented so that I know the rules I am bound of while collaborating within Eiffel Community.

As an Eiffel Community Member, I would like the duplicated community documentation moved from other repositories to community repository so that I can have one set of guidelines for all Eiffel Projects and the community.

Description

A suggestion on a recent community meeting was to make the default community health files more visible.

Motivation

The lack of CODE_OF_CONDUCT.md and CONTRIBUTING.md files in specific repositories might bring questions regarding the existence of such files. They are instead placed in the .github repository in order to create default files for every repository. Some users might miss this connection.

Exemplification

Benefits

See motivation

Possible Drawbacks

As an Eiffel Community Member, I would like the project maintainers identified so that I know who to talk to when it comes to project/technical topics.

Description

We need to have different label options to say the priority of the bug, so that when a user creates a bug can place these labels with options ranging from low to blocker (something similar to how JIRA provides)

Motivation

We have lots of issues on Github, but we never know what are the priority ones that needs to be addressed. By adding the priority labels it will be easier to identify what needs to be taken care of first.

Exemplification

Benefits

Easier planning of what to prioritize.

Possible Drawbacks

As an Eiffel Community Member, I would like the Technical Committee Charter documented so that I know the roles, responsibilities, and way of working of the committee.

As an Eiffel Community Member, I would like the list of existing Eiffel projects and their repositories documented so that I know what is developed by Eiffel Community and where.

As an Eiffel Community Member, I would like a README file created for the community repository so that I know what Eiffel Community is about and can find the links to guidelines, charted, and process documents.

Description

Eiffel TC members have permission to review, approve, and accept PRs coming to specific repositories.
These repos should be listed for increased visibility.

Motivation

Increase visibility.

Exemplification

N/A

Benefits

Increased visibility.

Possible Drawbacks

N/A

Description

Add information about our Eiffel Slack so people new to the community can ask questions or join the community easier.

Motivation

People new to the community needs to know how to get in touch with community members. Outside of GitHub we have Google groups and Slack but only Google groups is mentioned currently.

Exemplification

Something like

# Contact
* Mail list
* Slack channel
* etc ...

can be placed in the README.md or in the CONTACT.md perhaps?

Benefits

Easier access to someone in the Eiffel community, aside from a mail list.

Possible Drawbacks

Description

Eiffel Bootstrap Technical Committee (BTC) decided to call elections within the community to move to elected TC based on meritocracy during its meeting on March 25, 2021.

Motivation

Track and record the work done to conduct Eiffel Technical Committee elections.

Exemplification

Open source communities move to meritocratic governance model as part of their maturity.

Benefits

Moving to meritocratic TC helps community members to take active part in steering the community based on their knowledge, competence, and experience while bringing in diversity and different opinions.

Possible Drawbacks

N/A

Description

Describe how to handle dependencies between repositories.

Currently Eiffel Intelligence Frontend is dependent on Eiffel Intelligence . If the front-end requires a feature in the back-end there is no point in releasing or building a Docker container for the front-end until the back-end has the functionality merged.

In ETOS on the other hand there is a wish to build the containers on every merge.

Motivation

Need a unified way of handling dependencies between repositories.

Exemplification

See description

Benefits

Avoiding unusable releases and docker containers

Possible Drawbacks

N/A

Description

Create a new project

Name: eiffel-playground
Description: A playground repository to test GitHub specific features not suitable to test with real repositories e.g. perform releases to trigger an automatic build engine, doing dummy pull requests to trigger automatic pipelines, etc.
License: Apache 2.0
Maintainers: All

As an Eiffel Community Member, I would like the project license documented so that I know which license project uses.

Description

We need a howto to describe how to work with the logo image(s)

Motivation

It helps

Exemplification

Create a howto md file describing how to work with the logos

Benefits

Less time need to be invested every time an update is needed

Possible Drawbacks

None

Description

Setup a slack channel for Eiffel community

Motivation

We see the need of an instant messaging app. Slack was proposed at Eiffel Summit 2019.2 as the best alternative.

Description

The Eiffel Protocol Github project should move to graduated stage.

Motivation

• Eiffel Protocol is in production use by Ericsson and Axis
• Eiffel Protocol is maintained by people from both Ericsson and Axis
• Eiffel Protocol has got contributions from several people over the last few years. Quite few contributions have actually been made lately, but as Eiffel Protocol is the base for almost all other projects in the Eiffel Community, it should be considered Graduated to enable other more active projects to also graduate

Exemplification

Benefits

Showing to the world that the protocol is in production use

Possible Drawbacks

Description

Move logo GIMP file (logo-sources/eiffel-community-logos.xcf) to this repository instead of at eiffel-repository-template repository.

Also make sure to update description in eiffel-repository-template so that members know that this file exists.

Motivation

@e-backmark-ericsson left a comment in eiffel-community/eiffel-repository-template#1:

I'd say the update looks good. This logo template should probably not be in the template repo when the new community repo structure is finalized, as it would be copied into all new community repos then, but as long as it stays here I think the new image structure is good.

Benefits

It make logical sense to have this kind of resource in this repository

Possible Drawbacks

If a member is used to having it in https://github.com/eiffel-community/eiffel-repository-template they might have problem finding the file.

Description

We should have a folder where we can put presentations and more from our summits

Motivation

Version controlled summit material

Exemplification

Benefits

Possible Drawbacks

Clutter the repo?

Description

As documented in the governance, Eiffel Community has been operating in bootstrap mode and served by a special committee with appointed members named Bootstrap Technical Committee (BTC).
As part of the bootstrap phase, BTC created missing and updated existing community processes and procedures.

BTC agreed to call for community elections to compose a new TC based on meritocracy which means that the governance document can be updated to reflect the fact that the community concluded the bootstrap phase and switched to normal mode of operations.
Because of this, it is required to update the governance document, remove the bootstrap process, and make necessary amendments.

Please note that this must be approved by the newly elected TC and driven by the newly elected TC Chair and not by the BTC since newly elected TC may determine to take parts of the bootstrap process and incorporate it to governance.

Motivation

Reflect the maturity of the community and keep the governance up to date.

Exemplification

This is a common practice within open source communities.

Benefits

Maturity of the community is communicated clearly & transparently and governance is kept up to date.

Possible Drawbacks

N/A

Description

Eiffel Community needs to document the process it follows for security/vulnerability reporting and response so the users who identify such issues know where and how to report them. The process will also need to document who shall receive such reports, how they should be handled, fixed, and disclosed publicly.

Motivation

Security/vulnerability issues shall be reported, addressed, and disclosed in a proper manner without exposing users with vulnerable software to risk.

Exemplification

See processes of Jenkins and Spinnaker as processes.

Benefits

Security/vulnerability issues can be reported, addressed, and disclosed in a proper manner without exposing users with vulnerable software to risk.

Possible Drawbacks

N/A