You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+89-7Lines changed: 89 additions & 7 deletions
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,23 @@
1
-
# Welcome!
1
+
# Contributing to .NET for Apache Spark!
2
2
3
3
If you are here, it means you are interested in helping us out. A hearty welcome and thank you! There are many ways you can contribute to the .NET for Apache Spark project:
4
4
5
-
* Offer PR's to fix bugs or implement new features.
6
-
* Give us feedback and bug reports regarding the software or the documentation.
7
-
* Improve our examples, tutorials, and documentation.
5
+
* Offer PR's to fix bugs or implement new features
6
+
* Review currently [open PRs](https://github.com/dotnet/spark/pulls)
7
+
* Give us feedback and bug reports regarding the software or the documentation
8
+
* Improve our examples, tutorials, and documentation
8
9
9
-
## Getting started:
10
+
Please start by browsing the [issues](https://github.com/dotnet/spark/issues) and leave a comment to engage us if any of them interests you. And don't forget to take a look at the project [roadmap](https://github.com/dotnet/spark/blob/master/ROADMAP.md).
11
+
12
+
Here are a few things to consider:
13
+
14
+
* Before starting working on a major feature or bug fix, please open a GitHub issue describing the work you are proposing. We will make sure no one else is already working on it and the work aligns with the project [roadmap](https://github.com/dotnet/spark/blob/master/ROADMAP.md).
15
+
* A "major" feature or bug fix is defined as any change that is > 100 lines of code (not including tests) or changes user-facing behavior (e.g., breaking API changes). Please read [Proposing Major Changes to .NET for Apache Spark](#proposing-major-changes-to-net-for-apache-spark) before you begin any major work.
16
+
* Once you are ready, you can create a PR and the committers will help reviewing your PR.
Please make sure to take a look at the project [roadmap](ROADMAP.md).
12
23
@@ -22,10 +33,81 @@ A .NET for Apache Spark team member will be assigned to your pull request once t
22
33
23
34
All commits in a pull request will be squashed to a single commit with the original creator as author.
24
35
25
-
# Contributing
36
+
###Contributing
26
37
27
38
See [Contributing](docs/contributing.md) for information about coding styles, source structure, making pull requests, and more.
28
39
29
-
# Developers
40
+
###Developers
30
41
31
42
See the [Developer Guide](docs/developer-guide.md) for details about developing in this repo.
43
+
44
+
## Proposing major changes to .NET for Apache Spark
45
+
46
+
The development process in .NET for Apache Spark is design-driven. If you intend of making any significant changes, please consider discussing with the .NET for Apache Spark community first (and sometimes formally documented), before you open a PR.
47
+
48
+
The rest of this document describes the process for proposing, documenting and implementing changes to the .NET for Apache Spark project.
49
+
50
+
To learn about the motivation behind .NET for Apache Spark, see the following talk:
51
+
-[Introducing .NET Bindings for Apache Spark](https://databricks.com/session/introducing-net-bindings-for-apache-spark) from Spark+AI Summit 2019.
52
+
-[.NET for Apache Spark](https://databricks.com/session_eu19/net-for-apache-spark) from Spark+AI Europe Summit 2019.
53
+
54
+
### The Proposal Process
55
+
56
+
The process outlined below is for reviewing a proposal and reaching a decision about whether to accept/decline a proposal.
57
+
58
+
1. The proposal author [creates a brief issue](https://github.com/dotnet/spark/issues/new?assignees=&labels=untriaged%2C+proposal&template=design-template.md&title=%5BPROPOSAL%5D%3A+) describing the proposal.
59
+
2. A discussion on the issue will aim to triage the proposal into one of three outcomes:
60
+
- Accept proposal
61
+
- Decline proposal
62
+
- Ask for a detailed doc
63
+
If the proposal is accepted/declined, the process is done. Otherwise, the discussion is expected to identify concerns that should be addressed in a more detailed design.
64
+
3. The proposal author follows up with a detailed description to work out details of the proposed design and address the concerns raised in the initial discussion.
65
+
4. Once comments and revisions on the design are complete, there is a final discussion on the issue to reach one of two outcomes:
66
+
- Accept proposal
67
+
- Decline proposal
68
+
69
+
After the proposal is accepted or declined (e.g., after Step 2 or Step 4), implementation work proceeds in the same way as any other contribution.
70
+
71
+
> **Tip:** If you are an experienced committer and are certain that a design description will be required for a particular proposal, you can skip Step 2.
72
+
73
+
### Writing a Design Document
74
+
75
+
As noted [above](#the-proposal-process), some (but not all) proposals need to be elaborated in a design description.
76
+
77
+
- The design description should follow the template outlined below
78
+
```
79
+
Proposal:
80
+
81
+
Rationale:
82
+
83
+
Compatibility:
84
+
85
+
Design:
86
+
87
+
Implementation:
88
+
89
+
Impact on Performance (if applicable):
90
+
91
+
Open issues (if applicable):
92
+
```
93
+
94
+
- Once you have the design description ready and have addressed any specific concerns raised during the initial discussion, please reply back to the original issue.
95
+
- Address any additional feedback/questions and update your design description as needed.
96
+
97
+
### Proposal Review
98
+
99
+
A group of .NET for Apache Spark team members will review your proposal and CC the relevant developers, raising important questions, pinging lapsed discussions, and generally trying to guide the discussion toward agreement about the outcome. The discussion itself is expected to happen on the issue, so that anyone can take part.
100
+
101
+
### Consensus and Disagreement
102
+
103
+
The goal of the proposal process is to reach general consensus about the outcome in a timely manner.
104
+
105
+
If general consensus cannot be reached, the proposal review group decides the next step by reviewing and discussing the issue and reaching a consensus among themselves.
106
+
107
+
## Becoming a .NET for Apache Spark Committer
108
+
109
+
The .NET for Apache Spark team will add new committers from the active contributors, based on their contributions to the .NET for Apache Spark project. The qualifications for new committers are derived from [Apache Spark Contributor Guide](https://spark.apache.org/contributing.html):
110
+
111
+
-**Sustained contributions to .NET for Apache Spark**: Committers should have a history of major contributions to .NET for Apache Spark. An ideal committer will have contributed broadly throughout the project, and have contributed at least one major component where they have taken an “ownership” role. An ownership role means that existing contributors feel that they should run patches for this component by this person.
112
+
-**Quality of contributions**: Committers more than any other community member should submit simple, well-tested, and well-designed patches. In addition, they should show sufficient expertise to be able to review patches, including making sure they fit within .NET for Apache Spark’s engineering practices (testability, documentation, API stability, code style, etc). The committership is collectively responsible for the software quality and maintainability of .NET for Apache Spark.
113
+
-**Community involvement**: Committers should have a constructive and friendly attitude in all community interactions. They should also be active on the dev and user list and help mentor newer contributors and users. In design discussions, committers should maintain a professional and diplomatic approach, even in the face of disagreement.
0 commit comments