MISP
/
MISP
mirror of https://github.com/MISP/MISP
2
2
Fork 0
Code Issues Releases Wiki Activity

chg: [doc] Some minor changes

pull/7326/head
E. Cleopatra 2021-04-12 13:47:32 +01:00 committed by GitHub
parent 9fb8717f47
commit 2696246aa0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 21 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
GITWORKFLOW.md
View File

@ -8,18 +8,18 @@ For general GitHub usage information, see the [GitHub user documentation](https:
## Get started
To create your GitHub account, visit the [registration page](https://github.com/join) in a web browser.
Then you will be allowed to open new issues, create merge requests, and fork your own copy of our repositories.
Then you will be allowed to open new issues, create merge requests, and fork your copy of our repositories.
## Organisation
All of our repositories are available under the [MISP GitHub account](https://github.com/MISP).
The main Git repository and most issues live in the [MISP/MISP repository](https://github.com/MISP/MISP).
We use git to maintain all code for MISP project. We have divided the project into several components, each of which has its own separate repository. For example:
We use git to maintain all code for MISP Project. We have divided the project into several components, each of which has its own separate repository. For example:
- `MISP.git` – The core MISP code.
- `misp-taxonomies.git` – Taxonomies used in MISP taxonomy system and can be used by other information sharing tools.
- `misp-taxonomies.git` – Taxonomies used in MISP taxonomy system and can be used by other information-sharing tools.
- `misp-galaxy.git` – Clusters and elements to attach to MISP events or attributes (like threat actors).
- `misp-warninglists.git` – Warning lists to inform users of MISP about potential false-positives or other information in indicators.
- `misp-warninglists.git` – Warning lists to inform users of MISP about potential false positives or other information in indicators.
MISP code is divided into many git repositories for the following reasons:
- This creates natural boundaries between different code blocks, enforcing proper interfaces, and easing independent development to be conducted on various code parts at the same time, without the fear of running into conflicts.
@ -34,7 +34,7 @@ MISP uses several branches:
- Topic branches: We use topic branches, sometimes called `fix-*` and `feature-*`, respectively aimed at fixing a single bug and implementing a single new feature. Once ready, a topic branch is merged into the appropriate branch (generally the default branch). Until it has been merged, a topic branch's history may be rewritten.
When the MISP developers make a code change that resolves an issue, the GitHub issue will typically be closed from the relevant patch message.
The main MISP core branch, `2.4` (current stable version), that we consider as stable with frequent updates as hot-fixes.
The main MISP core branch, `2.4` (current stable version), that we consider as stable with frequent updates as hotfixes.
Features are developed in separated branches and then regularly merged into the `2.4` stable branch.
## How we use GitHub metadata
@ -47,10 +47,10 @@ The title should be a short but clear description of what this is about. Some pe
### Status and resolution
Open issues can have up to one status label, preceded by the letter "S". Each label has a description of what it represents.
Open issues may have a status label, starting with `S:`. Each label has a description of what it represents.
See the [list of status labels](https://github.com/MISP/MISP/labels?q=S%3A+), along with their descriptions.
Closed issue may have up to one resolution label, preceded by the letter "R". See the [list of resolution labels](https://github.com/MISP/MISP/labels?q=R%3A+), along with their descriptions. When an issue does not fit into MISP's mission, we reject it by creating a comment explaining why it's being rejected, closing the issue and the `R: wontfix` label. When an issue is closed as a duplicate, we create a comment that mentions the other, duplicated issue and add the `R: duplicate` label. If the issue is closed without one of the specific resolutions or a comment, then it means, by default, that the issue in question was fixed or the requested enhancement was implemented.
Closed issue may have up to one resolution label, starting with `R:`. See the [list of resolution labels](https://github.com/MISP/MISP/labels?q=R%3A+) and their descriptions. When an issue does not fit into MISP's mission, we reject it by creating a comment explaining why it's being rejected, closing the issue, and the `R: wontfix` label. When an issue is closed as a duplicate, we create a comment that mentions the other, duplicated issue and add the `R: duplicate` label. If the issue is closed without one of the specific resolutions or a comment, then it means, by default, that the issue in question was fixed or the requested enhancement was implemented.
The main advantage of using these labels is to organize and visualize issues on Issue Boards.
Using these labels accurately improves the team's workflow.
@ -70,12 +70,13 @@ This being said, we do assign them if at least one of these conditions is met:
### Milestone
Sometimes, Milestones are treated as a commitment, that other MISP contributors should be able to rely on.
Othertimes, it is use it as a pool of tasks they want to have on their short-term radar.
Sometimes, [Milestones](https://github.com/MISP/MISP/milestones) are treated as a commitment that other MISP contributors should be able to rely on.
Other times, it is used it as a pool of tasks they want to have on their short-term radar.
### Type of work
To indicate the type of work that's needed to complete the next step on an issue, we use labels whose name starts with T. See the [list of type of work labels](https://github.com/MISP/MISP/labels?q=t%3A) and their descriptions.
To indicate the type of work that's needed to complete the next step on an issue, we use labels that start with `T:`.
See the [list of the 'type of work' labels](https://github.com/MISP/MISP/labels?q=t%3A) and their descriptions.
### Other labels
@ -84,7 +85,7 @@ See our [full list of labels](https://code.briarproject.org/groups/briar/-/label
## Relationships between issues
GitHub is a bit limited when it comes to expressing semantic relationships between issues. Here is how we can overcome these limitations.
- Parent/subtask: Issues with the `T:meta` label indicate parent issues that have subtasks under it. In the child issues, a comment will be added mentioning the parent issue.
- Parent/subtask: Issues with the `T: meta` label indicate parent issues that have subtasks under it. In the child issues, a comment will be added mentioning the parent issue.
- Related issues: Related issues can be listed either in the description or in a comment. Either way, this adds a message in the activity stream of the referenced issue, with a link to the referencing issue.
## How to document progress
@ -106,7 +107,7 @@ It is important to:
- Keep the team informed of how you feel committed to issues assigned to you, and about the timeline you're envisioning.
- Avoid individual over-commitment & feelings of failure.
If you don't think you will manage to work on an issue any time soon, it's often best to make this clear on the issue, or to de-assign yourself.
If you don't think you will manage to work on an issue any time soon, it's often best to make this clear on the issue or to de-assign yourself.
### Propose changes
@ -117,22 +118,22 @@ You can comment on issues and pull requests.
To submit your work:
- Fork us on our GitHub
- Push your work to a dedicated git topic branch
- Once you would like your branch to be reviewed, and possibly merged, submit it by create a pull request (PR). In this new PR, use the description field to summarize what problem this PR will fix, in terms of impact on users and reference the issues this PR will solve, e.g "Closes #xxx, #yyyy".
- Once you would like your branch to be reviewed, and possibly merged, submit it by creating a pull request (PR). In this new PR, use the description field to summarize what problem this PR will fix, in terms of impact on users, and reference the issues this PR will solve, e.g "Closes #xxx, #yyyy".
Follow these conventions when submitting changes to any MISP Project repository:
- Submit one pull request (PR) per fix/feature/change. Don't split one feature into multiple PRs. Similarly, do not join several fixes and features into one pull request.
- Keep the amount of commits per PR as small as possible. If for any reason, you need to fix your commit after the pull request, please squash the changes in one single commit (or tell us why not).
- Keep the number of commits per PR as small as possible. If for any reason, you need to fix your commit after the pull request, please squash the changes in one single commit (or tell us why not).
- Always ensure your PR is mergeable in the default branch.
- Make sure Travis CI works on the PR, or update the test cases if needed.
- Any major changes adding a functionality should be disabled by default in the config.
### Request input from someone else
If you need input from someone else on an issue or pull request, ask your question in a comment there, mentioning them with their GitHub login name: @nick. If you want to raise attention of every single member of a team, mention it with the name of the corresponding group: @xyz-team. GitHub will send them an email notification about it.
If you need input from someone else on an issue or pull request, ask your question in a comment there, mentioning them with their GitHub login name: @nick. If you want to raise the attention of every single member of a team, mention it with the name of the corresponding group: @xyz-team. GitHub will send them an email notification about it.
### Act upon input requests
It's important to provide requested information as quickly as you can, to make the MISP contribution process more efficient and enjoyable.
It's important to provide the requested information as quickly as you can, to make the MISP contribution process more efficient and enjoyable.
When input is requested from you on an issue or pull request with @nick:
- GitHub may send you an email notification
@ -142,15 +143,15 @@ When you receive such a request, if you cannot provide the requested input immed
## Automatic integration and testing
MISP core uses CodeQL and LGTM for some code analysis and security checks. When you submit a PR, consider the results of checks. In addition, ensure that your code builds without errors.
MISP core uses CodeQL and LGTM for some code analysis and security checks. When you submit a PR, consider the results of checks. Also, ensure that your code builds without errors.
The majority of the repositories within the MISP GitHub organisation includes automatic integration with [TravisCI](https://travis-ci.org/MISP).
The majority of the repositories within the MISP GitHub organisation include automatic integration with [TravisCI](https://travis-ci.org/MISP).
If you contribute and make a pull request, verify if your changes affect the result of the tests.
Automatic integration is not perfect including Travis but it’s a quick way to catch new bugs or major issues in contribution.
When you make a pull-request, TravisCI is automatically called. If there are failing checks, no worries, review the output at Travis (it’s not
When you make a pull request, TravisCI is automatically called. If there are failing checks, no worries, review the output at Travis (it’s not
always you).
## Access control
If you need to do something in GitHub and you appear to lack the needed credentials, please ask the MISP team to grant you more power.
For example, you will need "Triage" access in order to add labels or assign issues. See [GitHub's access permissions documentation](https://docs.github.com/en/github/getting-started-with-github/access-permissions-on-github).
For example, you will need "Triage" access to add labels or assign issues. See [GitHub's access permissions documentation](https://docs.github.com/en/github/getting-started-with-github/access-permissions-on-github).