Skip to content

Commit df31d47

Browse files
authored
Change repo-specific references to generic (eiffel-community#2)
* Change repository-specific references and links to generic references and links, so that any repository can use these files.
1 parent 4b85b67 commit df31d47

File tree

2 files changed

+4
-4
lines changed

2 files changed

+4
-4
lines changed

CODE_OF_CONDUCT.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -34,7 +34,7 @@ This Code of Conduct applies both within project spaces and in public spaces whe
3434

3535
## Enforcement
3636

37-
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team via the [repository maintainers](mailto:repo-maintainers@mailing-list-placeholder.com). All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
37+
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team via the [repository maintainers](https://github.com/eiffel-community/community/blob/master/CONTACT.md). All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
3838

3939
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
4040

CONTRIBUTING.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -21,7 +21,7 @@ Thank you for contributing to the Eiffel Community!
2121
The following is a set of guidelines for contributing to this repository.
2222

2323
## How to Propose Changes
24-
Anyone is welcome to propose changes to the contents of this repository by creating a new [Issue](https://github.com/eiffel-community/eiffel-repository-template/issues) ticket in GitHub. These requests may concern anything contained in the repo: changes to documentation, bug fixes, requests for additional information, additional event types, requests for additional examples, new featuers et cetera.
24+
Anyone is welcome to propose changes to the contents of this repository by creating a new Issue ticket in GitHub. These requests may concern anything contained in the repo: changes to documentation, bug fixes, requests for additional information, additional event types, requests for additional examples, new featuers et cetera.
2525

2626
When posting a new issue, try to be as precise as possible and phrase your arguments for your request carefully. Keep in mind that collaborating on software development is often an exercise in finding workable compromises between multiple and often conflicting needs; this is particularly true for defining a shared protocol such as Eiffel. In particular, pay attention to the following:
2727
1. What type of change is requested?
@@ -33,7 +33,7 @@ When posting a new issue, try to be as precise as possible and phrase your argum
3333
Also, keep in mind that just as anyone is welcome to propose a change, anyone is welcome to disagree with and criticize that proposal.
3434

3535
### Closing Issues
36-
An Issue can be closed by any member of [the repository maintainers' team](https://github.com/orgs/eiffel-community/teams/eiffel-repository-template-maintainers). This can happen in various ways, for varying reasons:
36+
An Issue can be closed by any member of [the repository maintainers' team](https://github.com/eiffel-community/community/blob/master/CONTACT.md). This can happen in various ways, for varying reasons:
3737
1. Issues without conclusion and no activity for at least 14 days may be closed, as a mere housekeeping activity. For instance, an Issue met with requests for further clarification, but left unanswered by the original author, may simply be removed.
3838
1. Issues may simply be rejected if found unfeasible or undesirable. In such cases they shall also be responded to, providing a polite and concise explanation as to why the proposal is rejected.
3939
1. Issues may be closed because they are implemented. Following the successful merging of a pull request addressing an Issue, it will be closed.
@@ -49,7 +49,7 @@ Contributions can be made by anyone using the standard [GitHub Fork and Pull mod
4949
### Reviewing and Merging Pull Requests
5050
We use the Squash and Merge model, which means that all commits in a Pull Request get squashed into a single commit in the target branch. In other words, the revision history will look like a string of single commits corresponding one-to-one with Issues.
5151

52-
Pull requests can be merged by members of the [the repository maintainers' team](https://github.com/orgs/eiffel-community/teams/eiffel-repository-template-maintainers). There is a certain protocol to adhere to, however, as well as expectations on membership.
52+
Pull requests can be merged by members of the [the repository maintainers' team](https://github.com/eiffel-community/community/blob/master/CONTACT.md). There is a certain protocol to adhere to, however, as well as expectations on membership.
5353
1. All maintainers are expected to make the effort to participate in the review of Pull Requests. Every maintainer may not review everything in detail, but everyone can make the effort to chime in on some. Remember that expedient high quality reviews are crucial to the long term survival of any open source project.
5454
1. All community members, maintainers or not, are strongly encouraged to participate in reviews even if they do not feel entirely qualified to assess the pull request. Looking at changes and participating in review discussions is one of the best ways to learn, and presents an excellent opportunity to ask questions. And remember, participating in a review is not the same as having to make the final decision.
5555
1. A Pull Request should be approved by at least two maintainers (including the one doing the merging). For this to function well, the above point on participation is critical.

0 commit comments

Comments
 (0)