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
Improvements to the Cypher query language are managed through documents describing each feature of the language.
6
6
Such a document is called a _Cypher Improvement Proposal_, or _CIP_ for short.
7
+
8
+
=== Cypher Improvement Requests (CIRs)
9
+
10
+
Before a language feature or change is mature enough for a full CIP to be created, it may be requested through the creation of a _Cypher Improvement Request_, or _CIR_.
11
+
A CIR is created by raising an issue to this GitHub repository, which follows some conventions:
12
+
13
+
* The title should be a summary of the proposed change
14
+
* The issue should have a heading following this naming scheme:
15
+
** `CIR-{YYYY}-{number}`, where `{YYYY}` is the current year (four numbers) and `{number}` is the number of the GitHub issue (this may be edited in after creation of the issue to get the number correct).
16
+
17
+
A CIR is intended to be a light-weight document for requirements gathering, and does not need to fully consider all details of the proposal initially.
18
+
This will be explored as the CIR develops and more people join the discussion.
19
+
20
+
==== Lifecycle
21
+
22
+
During the lifetime of a CIR, it may change in nature.
23
+
It is preferable to keep the top post of the CIR updated with recent discussions, to allow new readers to easily get an updated view on what the CIR reflects, rather than have to scroll through a large history of change.
24
+
25
+
The ultimate goal of a CIR is to spawn the creation (and subsequent acceptance) of one or more CIPs.
26
+
27
+
=== Cypher Improvement Proposals (CIPs)
28
+
29
+
Proposals for improving the Cypher query language should take the form of a CIP.
30
+
A CIP is represented as a pull request against this repository, proposing the addition of a document following a few conventions:
31
+
32
+
* The name of the document should be on the form `CIP{year}-{month}-{day}-{name}.adoc`.
33
+
** The `{name}` part of the filename is a very short name of the proposed change; for instance the keyword the proposal intends to add or modify.
34
+
If the "`{name}`" part contains multiple words, each word should be written using lower case characters, separated by a dash.
35
+
** The date portion of the name is the the initial date of proposing the CIP (typically the same date as the submission of the pull request).
36
+
* The document should be based on the CIP template document, to ensure a consistent structure with respect to other CIPs.
37
+
* If the CIP is based on one or more CIRs, these should be explicitly referenced in the document and the pull request message.
38
+
39
+
CIPs that additionally come with a reference implementation are very much appreciated, as is helps clarify the workings of the proposed improvement.
40
+
This would help make the handling of the proposal quicker, or perhaps even make it more likely to be accepted.
41
+
42
+
Suggestions and ideas are also welcome and much appreciated; these would best be submitted as "issues" in this repository on GitHub.
43
+
The expectation is that these would eventually result in a CIP being created.
44
+
45
+
==== Lifecycle
46
+
47
+
Typically, CIPs spawn from one or more CIRs.
48
+
A direct submission of a CIP is appropriate if the proposed changed is in the form of a concrete proposal.
49
+
By starting from a CIR, you will be able to judge how large the general interest for the feature is before you embark on writing the CIP.
50
+
Starting from a CIR also facilitates building an "experts group" that can work with you on the details of the proposal.
51
+
52
+
Once a CIP has been issued, it will enter a phase of review, eventually becoming either accepted (and the pull request merged) or rejected.
@@ -18,6 +18,8 @@ It is our aim to make the process of specifying and evolving the Cypher property
18
18
While we aim for the process to be open, this does not mean a public democracy, as all decisions are currently made by the Cypher Language Group (CLG).
19
19
That said, we are of course extremely grateful for comments and suggestions on how to improve the Cypher query language.
20
20
21
+
Refer to the link:CIP-PROCESS.adoc[Cypher Improvement Process] document for more details on CIPs, CIRs, their structure and lifecycle.
22
+
21
23
=== The Cypher Language Group
22
24
23
25
The Cypher Language Group consists of:
@@ -33,36 +35,6 @@ Petra additionally acts as secretary for the group, calling meetings and ensurin
33
35
34
36
Cypher was originally created by https://github.com/systay[Andrés Taylor].
35
37
36
-
=== Improvement Proposals
37
-
38
-
Ultimately, proposals for improving the Cypher query language should take the form of a _Cypher Improvement Proposal (CIP)_.
39
-
These should typically be proposed as pull requests against this repository, proposing the addition of a document following a naming scheme of `CIP{year}-{month}-{day}-{name}.asciidoc`.
40
-
The "`{name}`" part of the filename is a very short name of the proposed changed; for instance the keyword the proposal intends to add or modify.
41
-
If the "`{name}`" part contains multiple words, each word should be written using lower case characters, separated by a dash.
42
-
The date portion of the name is the the initial date of proposing the CIP (typically the same date as the submission of the pull request).
43
-
44
-
CIPs that additionally come with a reference implementation are very much appreciated, as is helps clarify the workings of the proposed improvement.
45
-
This would help make the handling of the proposal quicker, or perhaps even make it more likely to be accepted.
46
-
47
-
Suggestions and ideas are also welcome and much appreciated; these would best be submitted as "issues" in this repository on GitHub.
48
-
The expectation is that these would eventually result in a CIP being created.
49
-
50
-
==== What is a CIP?
51
-
52
-
A _Cypher Improvement Proposal_, or _CIP_ for short, is a document that details a change to Cypher.
53
-
54
-
55
-
==== The life cycle of a CIP
56
-
57
-
Proposing a change to Cypher starts by either submitting a CIP as a pull request to this repository, or by submitting a feature request.
58
-
A direct submission of a CIP is appropriate if the proposed changed is in the form of a concrete proposal.
59
-
A feature request is typically the preferred method of starting a proposal.
60
-
By starting from a feature request, you will be able to judge how large the general interest for the feature is before you embark on writing the CIP.
61
-
Starting from a feature request also facilitates building an "experts group" that can work with you on the details of the proposal.
62
-
63
-
The comment thread on the GitHub issue for the feature proposal is an excellent place for discussing ideas
64
-
65
-
66
38
=== Meeting notes
67
39
68
40
The Cypher Language Group published meeting notes from all the group meetings at https://opencypher.github.io/meeting-minutes/
0 commit comments