From dc1b1be1008d382e41ca1445106f17fb0bb8335f Mon Sep 17 00:00:00 2001 From: Charles d'Avernas Date: Fri, 9 Aug 2024 16:04:16 +0200 Subject: [PATCH] fix(Solution): Added and updated the project's documents (following GH community standards) feat(Solution): Added a new README file used to describe the project's community --- CODE_OF_CONDUCT.md | 5 ++ CONTRIBUTING.md | 98 +++++------------------ GOVERNANCE.md | 162 ++++++++++++++------------------------- MAINTAINERS.md | 2 +- OWNERS.md | 18 ----- README.md | 23 ++---- SECURITY.md | 41 ++++++++++ Synapse.sln | 55 +++++++++++-- code-of-conduct.md | 11 --- community/README.md | 15 ++++ maintainer-guidelines.md | 29 ------- 11 files changed, 196 insertions(+), 263 deletions(-) create mode 100644 CODE_OF_CONDUCT.md delete mode 100644 OWNERS.md create mode 100644 SECURITY.md delete mode 100644 code-of-conduct.md create mode 100644 community/README.md delete mode 100644 maintainer-guidelines.md diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md new file mode 100644 index 000000000..97e590eb0 --- /dev/null +++ b/CODE_OF_CONDUCT.md @@ -0,0 +1,5 @@ +# Code of Conduct + +This community adheres to the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md). + +To report any violations of the Code of Conduct, please contact the [CNCF Code of Conduct Committee](mailto:conduct@cncf.io). \ No newline at end of file diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 06e8b4d9f..086305bc3 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,91 +1,29 @@ -# Contributing to Synapse +# Contributing -This page contains information about reporting issues, how to suggest changes as -well as the guidelines we follow for how our documents are formatted. +Thank you for considering contributing to the Synapse project! Your contributions help improve the project and are greatly appreciated. Please follow the guidelines below to ensure a smooth and effective contribution process. -## Table of Contents +## How to Contribute -- [Reporting an Issue](#reporting-an-issue) -- [Suggesting a Change](#suggesting-a-change) -- [Spec Formatting Conventions](#spec-formatting-conventions) +### Reporting Issues -## Reporting an Issue +If you encounter any bugs or have suggestions for improvements, please report them using GitHub Issues: -To report an issue, or to suggest an idea for a change that you haven't had time -to write-up yet, open an [issue](https://github.com/serverlessworkflow/synapse/issues). It -is best to check our existing -[issues](https://github.com/serverlessworkflow/synapse/issues) first to see if a similar -one has already been opened and discussed. +1. Go to the [Issues page](https://github.com/serverlessworkflow/synapse/issues) of the repository. +2. Check if the issue has already been reported. If not, click on "New issue". +3. Provide a clear and concise description of the problem or suggestion. Include any relevant details or screenshots. -## Suggesting a Change +### Suggesting Enhancements -To suggest a change to this repository, submit a -[pull request](https://github.com/serverlessworkflow/synapse/pulls) (PR) with the complete -set of changes you'd like to see. See the -[Spec Formatting Conventions](#spec-formatting-conventions) section for the -guidelines we follow for how documents are formatted. +If you have ideas for new features or enhancements: -Each PR must be signed per the following section. +1. Open a new issue on the [Issues page](https://github.com/serverlessworkflow/synapse/issues). +2. Clearly describe the enhancement or feature request and explain why it would be valuable. -### Assigning and Owning work +### Submitting Pull Requests -If you want to own and work on an issue, add a comment or “#dibs” it asking -about ownership. A maintainer will then add the Assigned label and modify the -first comment in the issue to include `Assigned to: @person` +To contribute code changes, please follow these steps: -## Spec Formatting Conventions - -Documents in this repository will adhere to the following rules: - -- Lines are wrapped at 80 columns (when possible) -- Specifications will use [RFC2119](https://tools.ietf.org/html/rfc2119) - keywords to indicate normative requirements - -## Checks - -### Markdown style - -Markdown files should be properly formatted before a pull request is sent out. -In this repository we follow the -[markdownlint rules](https://github.com/DavidAnson/markdownlint#rules--aliases) -with some customizations. See [markdownlint](.markdownlint.yaml) or -[settings](.vscode/settings.json) for details. - -We highly encourage to use line breaks in markdown files at `80` characters -wide. There are tools that can do it for you effectively. Please submit proposal -to include your editor settings required to enable this behavior so the out of -the box settings for this repository will be consistent. - -If you are using Visual Studio Code, -you can also use the `fixAll` command of the -[vscode markdownlint extension](https://github.com/DavidAnson/vscode-markdownlint). - -To otherwise check for style violations, use - -```bash -# Ruby and gem are required for mdl -gem install mdl -mdl -c .mdlrc . -``` - -To fix style violations, follow the -[instruction](https://github.com/DavidAnson/markdownlint#optionsresultversion) -with the Node version of markdownlint. - -### Typos - -In addition, please make sure to clean up typos before you submit the change. - -To check for typos, you may use - -```bash -# Golang is needed for the misspell tool. -make install-misspell -make misspell -``` - -To quickly fix typos, use - -```bash -make misspell-correction -``` +1. **Fork the repository**: Create a personal fork of the repository on GitHub. +2. **Clone your fork**: Clone the forked repository to your local machine. + ```bash + git clone https://github.com//synapse.git diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 525ef5a90..fa81158d0 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -1,138 +1,94 @@ -# Synapse Project Governance +# Governance -As a CNCF member project, we abide by the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). +As a CNCF member project, Synapse adheres to the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). -For specific guidance on practical contribution steps for any Synapse sub-project please -see our [contributing guide](CONTRIBUTING.md). +For specific guidance on contributing to Synapse, please refer to our [contributing guide](contributing.md). -You can contact the project maintainers at any time by sending an email to the -[Synapse WMS Maintainers](mailto:cncf-serverlessws-maintainers@lists.cncf.io) - mailing list. +For any questions or concerns, contact the project maintainers via the [Serverless Workflow Specification Maintainers](mailto:cncf-serverlessws-maintainers@lists.cncf.io) mailing list. ## Maintainership -Main responsibilities of maintainers include: +### Responsibilities -1) They share responsibility in the project's success. -2) They have made a long-term, recurring time investment to improve the project. -3) They spend that time doing whatever needs to be done, not necessarily what -is the most interesting or fun. +Maintainers are responsible for: + +1. Ensuring the project's overall success. +2. Committing significant time and effort to enhance the project. +3. Handling necessary tasks, even those that may not be the most engaging. ## Reviewers -A reviewer is a core role within the project. -They share in reviewing issues and pull requests. Their pull request approvals -are needed to merge a large code change into the project. - -## Adding maintainers - -Maintainers are first and foremost contributors that have shown they are -committed to the long term success of a project. Contributors wanting to become -maintainers are expected to be deeply involved in contributing code, pull -request review, and triage of issues in the project for more than three months. - -Just contributing does not make you a maintainer, it is about building trust -with the current maintainers of the project and being a person that they can -depend on and trust to make decisions in the best interest of the project. - -Periodically, the existing maintainers curate a list of contributors that have -shown regular activity on the project over the prior months. From this list, -maintainer candidates are selected and proposed on the project mailing list. - -After a candidate has been announced on the project mailing list, the -existing maintainers are given fourteen business days to discuss the candidate, -raise objections and cast their vote. Votes may take place on the mailing list -or via pull request comment. Candidates must be approved by at least 66% of the -current maintainers by adding their vote on the mailing list. The reviewer role -has the same process but only requires 33% of current maintainers. Only -maintainers of the repository that the candidate is proposed for are allowed to -vote. - -If a candidate is approved, a maintainer will contact the candidate to invite -the candidate to open a pull request that adds the contributor to the -[MAINTAINERS](MAINTAINERS.md) file. The voting process may take place inside a pull request if a -maintainer has already discussed the candidacy with the candidate and a -maintainer is willing to be a sponsor by opening the pull request. The candidate -becomes a maintainer once the pull request is merged. +Reviewers play a crucial role by: -## Subprojects +- Reviewing and approving issues and pull requests. +- Approving pull requests is necessary for code changes to be merged into the project. + +## Emeritus Maintainers -Synapse subprojects all culminate in officially supported and maintained releases -of the specification. -All subprojects must adhere to [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) -as well as this governance document. +Emeritus maintainers are former maintainers who have significantly contributed to the project but are no longer able to be actively involved. They continue to: -### Adding core subprojects +1. Provide guidance and mentorship to current maintainers and contributors. +2. Offer historical context and insights based on their past experiences. +3. Participate in discussions and reviews on an advisory basis. -New subprojects can request to be added to the Synapse GitHub -organization by submitting a GitHub issue in the specification repository. +## Adding Maintainers -The existing maintainers are given fourteen business days to discuss the new -project, raise objections and cast their vote. Projects must be approved by at -least 66% of the current maintainers. +To add a new maintainer: -If a project is approved, a maintainer will add the project to the Synapse -GitHub organization, and make an announcement on a public Slack channel. +1. Candidates must demonstrate strong, ongoing commitment to the project by actively contributing, reviewing pull requests, and managing issues for at least three months. +2. Current maintainers review and propose new maintainers through a pull request. +3. A candidate requires at least 66% approval from existing maintainers to be added. Only one maintainer per organization is allowed. -## Stepping down policy +For the reviewer role, candidates need 33% approval from current maintainers. -Life priorities, interests, and passions can change. If you're a maintainer but -feel you must remove yourself from the list, inform other maintainers that you -intend to step down, and if possible, help find someone to pick up your work. -At the very least, ensure your work can be continued where you left off. +## Adding Emeritus Maintainers -After you've informed other maintainers, create a pull request to remove -yourself from the MAINTAINERS file. +To transition a maintainer to emeritus status: -## Removal of inactive maintainers +1. Follow the same voting and approval process as for adding new maintainers. +2. A pull request is created for the transition, requiring a 66% approval vote from current maintainers. +3. Once approved, the emeritus maintainer is added to the EMERITUS file and announced to the community. + +## Subprojects -Similar to the procedure for adding new maintainers, existing maintainers can -be removed from the list if they do not show significant activity on the -project. Periodically, the maintainers review the list of maintainers and their -activity over the last three months. +### Adding Core Subprojects -If a maintainer has shown insufficient activity over this period, a neutral -person will contact the maintainer to ask if they want to continue being -a maintainer. If the maintainer decides to step down as a maintainer, they -open a pull request to be removed from the MAINTAINERS file. +1. To add a new subproject, submit a GitHub issue in the specification repository. +2. Existing maintainers have fourteen business days to discuss and vote on the proposal. +3. A subproject requires at least 66% approval from current maintainers. -If the maintainer wants to remain a maintainer, but is unable to perform the -required duties they can be removed with a vote of at least 66% of -the current maintainers. An e-mail is sent to the -mailing list, inviting maintainers of the project to vote. The voting period is -fourteen business days. Issues related to a maintainers performance should be -discussed with them among the other maintainers so that they are not surprised -by a pull request removing them. +### Stepping Down -## How are decisions made? +Maintainers intending to step down should: -Synapse is an open-source project with an open design philosophy. This means -that the repository is the source of truth for EVERY aspect of the project, -including its philosophy, design, road map, and APIs. *If it's part of the -project, it's in the repository. If it's in the repository, it's part of the project.* +1. Inform other maintainers and, if possible, help find a successor. +2. Open a pull request to remove their name from the MAINTAINERS file. -As a result, all decisions can be expressed as changes to the repository. An -implementation change is a change to the source code. An API change is a change -to the API specification, and so on. +## Removal of Inactive Maintainers -All decisions affecting Synapse, big and small, follow the same 3 steps: +Inactive maintainers are reviewed periodically. If a maintainer has not been active for three months: -* Step 1: Open a pull request. Anyone can do this. +1. A neutral person will contact them to confirm their desire to continue. +2. If they wish to step down, a pull request is opened to remove them from the MAINTAINERS file. +3. If they wish to remain but cannot perform their duties, they can be removed with a 66% vote from the current maintainers. -* Step 2: Discuss the pull request. Anyone can do this. +## Decision-Making Process -* Step 3: Merge or refuse the pull request. Who does this depends on the nature -of the pull request and which areas of the project it affects. +Decisions are made through: -## I'm a maintainer. Should I make pull requests too? +1. Opening a pull request, which anyone can do. +2. Discussing the pull request, which anyone can contribute to. +3. Merging or refusing the pull request, which depends on the nature of the change. -Yes. Nobody should ever push to master directly. All changes should be -made through a pull request. +Consensus among maintainers is required for significant decisions. Proposals should be discussed before opening a pull request. + +## Maintainer Pull Requests + +Maintainers must also make changes via pull requests. Direct pushes to master are not allowed. For details, see the [Contributing](contributing.md) guide. ## Conflict Resolution -If you have a technical dispute that you feel has reached an impasse with a -subset of the community, any contributor may open an issue, specifically -calling for a resolution vote of the current core maintainers to resolve the dispute. -The same voting quorums required (2/3) for adding and removing maintainers -will apply to conflict resolution. \ No newline at end of file +To merge changes, at least one maintainer must approve the pull request. If maintainers do not voice their opinions within two days, their approval is assumed via [lazy consensus](http://communitymgt.wikia.com/wiki/Lazy_consensus). + +For disputes, efforts should be made to resolve issues amicably. If unresolved, a third-party maintainer can mediate. The core maintainers have the final say, making decisions by consensus or majority vote if necessary, ideally within two weeks. + diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 19f3d4801..8a0207797 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -1,4 +1,4 @@ -# Synapse Maintainers +# Maintainers * [Charles d'Avernas](https://github.com/cdavernas) * [Jean-Baptiste Bianchi](https://github.com/jbbianchi) \ No newline at end of file diff --git a/OWNERS.md b/OWNERS.md deleted file mode 100644 index 2394ccae2..000000000 --- a/OWNERS.md +++ /dev/null @@ -1,18 +0,0 @@ -See the [governance document](GOVERNANCE.md) for the definition of the roles and responsibilities - -## Maintainers: - -- [Charles d'Avernas](https://github.com/cdavernas) -- [Jean-Baptiste Bianchi](https://github.com/jbbianchi) - -## Reviewers: - -- [Charles d'Avernas](https://github.com/cdavernas) -- [Jean-Baptiste Bianchi](https://github.com/jbbianchi) -- [Tihomir Surdilovic](https://github.com/tsurdilo) - -## Approvers: - -- [Charles d'Avernas](https://github.com/cdavernas) -- [Jean-Baptiste Bianchi](https://github.com/jbbianchi) -- [Tihomir Surdilovic](https://github.com/tsurdilo) diff --git a/README.md b/README.md index 0fad25532..729524a61 100644 --- a/README.md +++ b/README.md @@ -124,26 +124,19 @@ For more information about `synctl`, please refer to the [documentation](#synctl ## Community -We have a growing community working together to build a community-driven and vendor-neutral -workflow ecosystem. Community contributions are welcome and much needed to foster project growth. +The Synapse project has a vibrant and growing community dedicated to building a community-driven and vendor-neutral workflow runtime ecosystem. Contributions from the community are encouraged and essential to the continued growth and success of the project. -See [here](community/contributors.md) for the list of community members that have contributed to the specification. +A list of community members who have contributed to Synapse can be found [here](./community/README.md). -To learn how to contribute to the specification reference the ['how to contribute'](contributing.md) doc. +To learn how to contribute to Synapse, please refer to the [contribution guidelines](CONTRIBUTING.md). -If you have any copyright questions when contributing to a CNCF project like this one, -reference the [Ownership of Copyrights in CNCF Project Contributions](https://github.com/cncf/foundation/blob/master/copyright-notices.md) doc. +For any copyright-related questions when contributing to a CNCF project like Synapse, please refer to the [Ownership of Copyrights in CNCF Project Contributions](https://github.com/cncf/foundation/blob/master/copyright-notices.md) document. ### Code of Conduct -As contributors and maintainers of this project, and in the interest of fostering -an open and welcoming community, we pledge to respect all people who contribute -through reporting issues, posting feature requests, updating documentation, -submitting pull requests or patches, and other activities. +As contributors and maintainers of Synapse, and in the interest of fostering an open and welcoming community, we commit to respecting all individuals who contribute through activities such as reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other forms of participation. -We are committed to making participation in this project a harassment-free experience for -everyone, regardless of level of experience, gender, gender identity and expression, -sexual orientation, disability, personal appearance, body size, race, ethnicity, age, -religion, or nationality. +The project is committed to making participation in Synapse a harassment-free experience for everyone, regardless of experience level, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality. + +For more detailed information, please see the full project Code of Conduct [here](code-of-conduct.md). -See our full project Code of Conduct information [here](code-of-conduct.md). diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 000000000..5cd45ae7e --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,41 @@ +# Security Policy + +## Reporting a Vulnerability + +The Synapse team and community take security vulnerabilities very seriously. Responsible disclosure of security issues is greatly appreciated, and every effort will be made to acknowledge and address your findings. + +To report a security issue: + +- **Use the GitHub Security Advisory**: Please use the ["Report a Vulnerability"](https://github.com/serverlessworkflow/synapse/security/advisories/new) tab on GitHub to submit your report. + +The Synapse team will acknowledge your report and provide details on the next steps. After the initial response, the security team will keep you informed of the progress towards a fix and any subsequent announcements. Additional information or guidance may be requested as necessary. + +## Security Best Practices + +To ensure the security and stability of Synapse as the runtime environment for the Serverless Workflow DSL, consider the following best practices: + +- **Runtime Environment Hardening**: Secure the underlying infrastructure where Synapse is deployed. This includes using up-to-date operating systems, applying security patches regularly, and configuring firewalls and security groups to limit access to only necessary ports and services. + +- **Secure Configuration Management**: Ensure that Synapse configuration files, especially those containing sensitive information like database credentials or API keys, are stored securely. Use environment variables or secret management tools to avoid hardcoding sensitive data. + +- **Container Security**: If running Synapse within containers, use hardened and minimal base images. Regularly scan container images for vulnerabilities, and avoid running containers with elevated privileges. Leverage container orchestration tools to enforce security policies, such as network segmentation and resource limits. + +- **Workflow Isolation**: Assign workflows to specific operators based on their namespace or organizational unit. This ensures that each sector or department has dedicated resources for running workflows in isolated environments, reducing the risk of unauthorized access and maintaining operational integrity. + +- **Logging and Monitoring**: Implement robust logging and monitoring for Synapse runtime operations. Ensure that logs capture relevant security events, such as unauthorized access attempts or unusual activity. Use monitoring tools to detect and alert on potential security incidents in real-time. + +- **Secure Communication Channels**: Ensure that all communication between Synapse and external services (e.g., APIs, databases) is encrypted using TLS. Validate certificates and use mutual TLS where possible to further secure communications. + +- **Access Control and Authentication**: Implement strict access control mechanisms within Synapse. Use Role-Based Access Control (RBAC) to define and enforce permissions for different users and services interacting with the runtime. Integrate with identity providers (e.g., OAuth, LDAP) for centralized authentication and authorization. + +- **Regular Security Audits**: Conduct regular security audits of the Synapse runtime environment, including code reviews, penetration testing, and vulnerability assessments. Address any findings promptly to maintain a secure operational environment. + +- **Incident Response Planning**: Develop and maintain an incident response plan specifically for Synapse. This should include procedures for identifying, containing, and remediating security incidents. Ensure that the plan is tested regularly and that the team is prepared to act swiftly in the event of a security breach. + +- **Backup and Recovery**: Implement a robust backup and recovery strategy for Synapse. Ensure that backups are encrypted, stored securely, and tested regularly to ensure data can be restored in case of a security incident or data corruption. + +By adhering to these best practices, the security of the Synapse runtime can be significantly enhanced, reducing the risk of vulnerabilities and ensuring the integrity and reliability of workflows executed within it. + +--- + +Thank you for contributing to the security and integrity of Synapse! \ No newline at end of file diff --git a/Synapse.sln b/Synapse.sln index 0bcb016a3..1db98f461 100644 --- a/Synapse.sln +++ b/Synapse.sln @@ -31,14 +31,13 @@ Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "Synapse.Api.Application", " EndProject Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "docs", "docs", "{C31B1410-C7AF-4D11-8DA5-6877756A9907}" ProjectSection(SolutionItems) = preProject - code-of-conduct.md = code-of-conduct.md - contributing.md = contributing.md - governance.md = governance.md + CODE_OF_CONDUCT.md = CODE_OF_CONDUCT.md + CONTRIBUTING.md = CONTRIBUTING.md + GOVERNANCE.md = GOVERNANCE.md LICENSE = LICENSE - maintainer-guidelines.md = maintainer-guidelines.md - maintainers.md = maintainers.md - owners.md = owners.md + MAINTAINERS.md = MAINTAINERS.md README.md = README.md + SECURITY.md = SECURITY.md EndProjectSection EndProject Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "tests", "tests", "{F041A1CB-45FA-4432-BAD2-DE2EE174C6FC}" @@ -79,6 +78,48 @@ Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "docker-compose", "docker-co EndProject Project("{E53339B2-1760-4266-BCC7-CA923CBCF16C}") = "docker-compose", "deployments\docker-compose\docker-compose.dcproj", "{A2D3AFB0-C7E0-4778-9D0A-DFCE0E24AF17}" EndProject +Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "community", "community", "{EFD78767-3171-46D2-880C-4E8F3C97529A}" + ProjectSection(SolutionItems) = preProject + community\README.md = community\README.md + EndProjectSection +EndProject +Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "assets", "assets", "{750922F9-5C47-42FE-945F-576818E6DEC9}" +EndProject +Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "images", "images", "{81124062-334B-4AE3-A538-92B044207A94}" + ProjectSection(SolutionItems) = preProject + assets\images\logo.eps = assets\images\logo.eps + assets\images\logo.svg = assets\images\logo.svg + assets\images\logomark.eps = assets\images\logomark.eps + assets\images\logomark.svg = assets\images\logomark.svg + assets\images\logomark_background.eps = assets\images\logomark_background.eps + assets\images\logomark_background.svg = assets\images\logomark_background.svg + assets\images\logomark_black.eps = assets\images\logomark_black.eps + assets\images\logomark_black.svg = assets\images\logomark_black.svg + assets\images\logomark_white.eps = assets\images\logomark_white.eps + assets\images\logomark_white.svg = assets\images\logomark_white.svg + assets\images\logo_background.eps = assets\images\logo_background.eps + assets\images\logo_background.svg = assets\images\logo_background.svg + assets\images\logo_black.eps = assets\images\logo_black.eps + assets\images\logo_black.svg = assets\images\logo_black.svg + assets\images\logo_white.eps = assets\images\logo_white.eps + assets\images\logo_white.svg = assets\images\logo_white.svg + assets\images\transparent_logo.png = assets\images\transparent_logo.png + assets\images\transparent_logomark.ico = assets\images\transparent_logomark.ico + assets\images\transparent_logomark.png = assets\images\transparent_logomark.png + assets\images\transparent_logomark_black.png = assets\images\transparent_logomark_black.png + assets\images\transparent_logomark_white.png = assets\images\transparent_logomark_white.png + assets\images\transparent_logo_black.png = assets\images\transparent_logo_black.png + assets\images\transparent_logo_white.png = assets\images\transparent_logo_white.png + EndProjectSection +EndProject +Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "fonts", "fonts", "{2A6EE5DF-BD7E-4CC6-BB9B-7BE5FC128302}" + ProjectSection(SolutionItems) = preProject + assets\fonts\Aquatico-Regular.otf = assets\fonts\Aquatico-Regular.otf + assets\fonts\Aquatico-Regular.ttf = assets\fonts\Aquatico-Regular.ttf + assets\fonts\Aquatico-Regular.woff = assets\fonts\Aquatico-Regular.woff + assets\fonts\Aquatico-Regular.woff2 = assets\fonts\Aquatico-Regular.woff2 + EndProjectSection +EndProject Global GlobalSection(SolutionConfigurationPlatforms) = preSolution Debug|Any CPU = Debug|Any CPU @@ -199,6 +240,8 @@ Global {1EA900CD-6CDE-4358-8412-060BF2AC3B21} = {F6CA60F0-3A4A-4B27-9805-6FA96F64D94D} {8DC6DDDC-0676-4FCB-9F82-570B84D1A5C2} = {562C91A3-6E91-4489-9D9D-064E7436D900} {A2D3AFB0-C7E0-4778-9D0A-DFCE0E24AF17} = {8DC6DDDC-0676-4FCB-9F82-570B84D1A5C2} + {81124062-334B-4AE3-A538-92B044207A94} = {750922F9-5C47-42FE-945F-576818E6DEC9} + {2A6EE5DF-BD7E-4CC6-BB9B-7BE5FC128302} = {750922F9-5C47-42FE-945F-576818E6DEC9} EndGlobalSection GlobalSection(ExtensibilityGlobals) = postSolution SolutionGuid = {2A6C03D6-355A-4B39-9F2B-D0FDE429C0E2} diff --git a/code-of-conduct.md b/code-of-conduct.md deleted file mode 100644 index 97a8526a6..000000000 --- a/code-of-conduct.md +++ /dev/null @@ -1,11 +0,0 @@ -# Code of Conduct - -We follow the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md). - - -Please contact the [CNCF Code of Conduct Committee](mailto:conduct@cncf.io) -in order to report violations of the Code of Conduct. diff --git a/community/README.md b/community/README.md new file mode 100644 index 000000000..662e08da9 --- /dev/null +++ b/community/README.md @@ -0,0 +1,15 @@ +# Community + +This document acknowledges the contributions of community members to the Synapse project. The Synapse community thrives on collaboration and the valuable input of its contributors. + +## Contributors + +The list below recognizes individuals and organizations who have made significant contributions to the Synapse project. + +We encourage everyone to join the Synapse community and contribute to the project. For more information on how to get involved, please refer to the ['how to contribute'](../CONTRIBUTING.md) guide. + +We strive to include all contributors in this list. If your name has been missed, feel free to add it through a pull request to this document, or notify us through our communication channels or during a team meeting. + +### [**Neuroglia**](https://neuroglia.io/) + * [Charles d'Avernas](https://github.com/cdavernas) + * [Jean-Baptiste Bianchi](https://github.com/JBBianchi) \ No newline at end of file diff --git a/maintainer-guidelines.md b/maintainer-guidelines.md deleted file mode 100644 index 742e371d3..000000000 --- a/maintainer-guidelines.md +++ /dev/null @@ -1,29 +0,0 @@ -# Maintainer's Guide - -## Tips - -Here are a few tips for repository maintainers. - -* Stay on top of your pull requests. PRs that languish for too long can become difficult to merge. -* Work from your own fork. As you are making contributions to the project, you should be working from your own fork just as outside contributors do. This keeps the branches in github to a minimum and reduces unnecessary CI runs. -* Try to proactively label issues with backport labels if it's obvious that a change should be backported to previous releases. -* When landing pull requests, if there is more than one commit, try to squash into a single commit. Usually this can just be done with the GitHub UI when merging the PR. Use "Squash and merge". -* Triage issues once in a while in order to keep the repository alive. During the triage: - * If some issues are stale for too long because they are no longer valid/relevant or because the discussion reached no significant action items to perform, close them and invite the users to reopen if they need it. - * If some PRs are no longer valid but still needed, ask the user to rebase them - * If some issues and PRs are still relevant, use labels to help organize tasks - * If you find an issue that you want to create a fix for and submit a pull request, be sure to assign it to yourself so that others maintainers don't start working on it at the same time. - -## Branch Management - -The `main` branch is the bleeding edge. New major versions of the project -are cut from this branch and tagged. If you intend to submit a pull request -you should use `main HEAD` as your starting point. - -Each major release will result in a new branch and tag. For example, the -release of version 1.0.0 of the project results in a `v1.0.0` tag on the -release commit, and a new branch `release-1.y.z` for subsequent minor and patch -level releases of that major version if necessary. However, development will continue -apace on `main` for the next major version - e.g. 2.0.0. Version branches -are only created for each major version. Minor and patch level releases -are simply tagged. \ No newline at end of file