eiffel-community / community Goto Github PK
View Code? Open in Web Editor NEWCommunity guidelines such as governance, how to contribute, code of conduct, etc
License: Apache License 2.0
Community guidelines such as governance, how to contribute, code of conduct, etc
License: Apache License 2.0
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 :)
ETOS
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.
ETOS will be licensed the same as every other project within the Eiffel community; under Apache 2.0.
Anders Josephson [email protected]
Fredrik Fristedt [email protected]
Tobias Persson [email protected]
ETOS is a large project with many microservices.
For starters we will need these repositories:
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.
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.
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.
N/A
Providing a good template based on PROJECT_LIFECYCLE.md is obviously beneficial for users and maintainers alike.
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.
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.
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.
N/A
Security/vulnerability issues are reported to and known by the Eiffel Community Members and not by public until they are fixed and disclosed.
N/A
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.
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.
Eiffel event repository API
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.
Will be licensed the same as every other project within the Eiffel community; under Apache 2.0.
Tobias Persson [email protected]
Magnus Bäck [email protected]
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.
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
So joining the community is an easier and welcoming thing
N/A
So joining the community is an easier and welcoming thing
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:
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.
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).
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.
See Motivation, above.
It would be another cloud-based entity owned and administered by the Eiffel community. Right now we only have the GitHub repositories.
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.
Enable Eiffel Community meeting agenda and notes to be available and editable publicly.
Various communities use HackMD.io for keeping notes such as Continuous Delivery Foundation.
Increased collaboration and visibility.
N/A
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
Switch to using inclusive language and analyse & prepare for potential impacts.
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
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.
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:
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
Go package for Eiffel events (aka go-eiffel)
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.
Apache Open Source License 2.0
Magnus Bäck (@magnusbaeck)
Tobias Persson (@t-persson)
Felix Hall (TBD)
Jonas Alfredsson (@JonasAlfredsson)
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).
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.
The role, its responsibilities, the appointed community members and their term documented in governance for transparency.
This is a common practice within open source communities.
Increased transparency and communication.
N/A
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
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.
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.
See above.
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.
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.
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).
Good to have a written down process to refer people to when introducing new repositories into the Eiffel community.
The howto guide could contain details on who to contact and of course references to the template repository.
See motivation.
As an Eiffel Community Member, I would like the contribution guidelines documented so that I know how to contribute.
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.
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.
Many communities have such environments to run tests or use for production purposes.
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.
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.
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.
Community adapted a new process for project lifecycle so this commit makes existing documentation inline with the process.
N/A
Updated instructions.
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.
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.
List members and chair of the BTC for increased visibility and transparency.
https://github.com/spinnaker/governance/tree/master/committee-technical-oversight#members
https://github.com/tektoncd/community/blob/master/governance.md#tekton-bootstrap-governance
Increased visibility and transparency.
N/A
Eiffel Community is an active community and there are times certain requests require to be handled. Some of the example requests are
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
Identify and document community support process and contacts who look after support issues.
Communities generally have list of interested/appointed people looking after support issues which Eiffel Community could adapt as well.
Increased visibility on how community support works and reduced workload on the current volunteers.
N/A
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.
Without this distinction it's more difficult than it should be for newcomers to get started. The overall impression of Eiffel suffers.
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.
Having information about the status of projects upfront makes it easier for potential users to estimate the effort needed for deployment.
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.
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.
Need a unified way of handling dependencies between repositories.
See description
Avoiding unusable releases and docker containers
N/A
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.
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.
https://www.jenkins.io/project/board-election-process/
https://wiki.opendaylight.org/display/ODL/TSC+Election+Process
Election process, including roles, rules, and exceptions documented.
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.
A suggestion on a recent community meeting was to make the default community health files more visible.
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.
See motivation
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.
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)
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.
Easier planning of what to prioritize.
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.
Eiffel TC members have permission to review, approve, and accept PRs coming to specific repositories.
These repos should be listed for increased visibility.
Increase visibility.
N/A
Increased visibility.
N/A
Add information about our Eiffel Slack so people new to the community can ask questions or join the community easier.
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.
Something like
# Contact
* Mail list
* Slack channel
* etc ...
can be placed in the README.md or in the CONTACT.md perhaps?
Easier access to someone in the Eiffel community, aside from a mail list.
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.
Track and record the work done to conduct Eiffel Technical Committee elections.
Open source communities move to meritocratic governance model as part of their maturity.
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.
N/A
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.
Need a unified way of handling dependencies between repositories.
See description
Avoiding unusable releases and docker containers
N/A
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.
We need a howto to describe how to work with the logo image(s)
It helps
Create a howto md file describing how to work with the logos
Less time need to be invested every time an update is needed
None
Setup a slack channel for Eiffel community
We see the need of an instant messaging app. Slack was proposed at Eiffel Summit 2019.2 as the best alternative.
The Eiffel Protocol Github project should move to graduated stage.
Showing to the world that the protocol is in production use
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.
@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.
It make logical sense to have this kind of resource in this repository
If a member is used to having it in https://github.com/eiffel-community/eiffel-repository-template they might have problem finding the file.
We should have a folder where we can put presentations and more from our summits
Version controlled summit material
Clutter the repo?
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.
Reflect the maturity of the community and keep the governance up to date.
This is a common practice within open source communities.
Maturity of the community is communicated clearly & transparently and governance is kept up to date.
N/A
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.
Security/vulnerability issues shall be reported, addressed, and disclosed in a proper manner without exposing users with vulnerable software to risk.
See processes of Jenkins and Spinnaker as processes.
Security/vulnerability issues can be reported, addressed, and disclosed in a proper manner without exposing users with vulnerable software to risk.
N/A
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.