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
{{ message }}
This repository was archived by the owner on Jun 7, 2023. It is now read-only.
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+7-6Lines changed: 7 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,27 +6,28 @@ We welcome contributions large and small to the Runestone Components. We welcom
6
6
Understand the RoadMap
7
7
----------------------
8
8
9
-
You should look at the [development road map](https://github.com/bnmnetp/runestone/wiki/DevelopmentRoadmap)
10
-
and especially RSE-0001 which gives you a clear idea of the current philosophy behind the components. Any
9
+
You should look at the [development road map](https://github.com/bnmnetp/runestone/wiki/DevelopmentRoadmap)
10
+
and especially RSE-0001 which gives you a clear idea of the current philosophy behind the components. Any
11
11
Sphinx directives should create very simple html and let Javascript take care of the rest.
12
12
13
13
Coding Standards
14
14
----------------
15
15
16
-
* All components must remain Python 3/2 compatible. The ``six`` module is already
16
+
* All components must be Python 3 compatible. The ``six`` module is already
17
17
in the requirements.txt file, so feel free to use that.
18
18
* No Tabs for Python files (4 spaces = 1 indention)
19
19
* Avoid profliferation of jQuery versions. Make your stuff compatible with the version
20
20
of jQuery in the common folder.
21
-
* Avoid proliferation of additional third party javascript modules. We are already out of
21
+
* Avoid proliferation of additional third party javascript modules. We are already out of
22
22
control in this regard and it would be nice to rein it in.
23
23
* When creating a new directive, assign a unique class name to the outermost HTML division. That will allow you to easily confine your CSS declarations to apply only within your directive. Since there are many directives, chances for CSS namespace conflicts are high without that.
24
24
* When making a new directive Also put the outer div in the runestone class, this makes it easy for us to select all runestone components on a page.
25
25
* When making any changes, make sure the docstring for the class that implements the Sphinx directive is up to date. These docstrings are used in several places for templates and quick help.
26
26
* Make sure your new directive class inherits and uses RunestoneBase
27
27
* Avoid writing a directive that returns a raw node. Creating appropriate nodes that inherit from Runestone gives us much more flexibility to auto number and cross reference and store source in the database.
28
28
* Make sure any buttons you create have their type specified. Unless you know you want it to be submit or reset make sure it is 'button' otherwise it causes problems for previewing.
29
-
29
+
* Keep Pull Requests small, and limit them to the feature you are adding or bug you are fixing.
30
+
* Please don't make gratuitous changes to the code to fit your own personal style or sense of what is correct or incorrect. In other words If it ain't broke, don't fix it. These kinds of changes make it harder for reviewers to figure out what you are trying to do.
30
31
31
32
Unit Testing
32
33
------------
@@ -39,7 +40,7 @@ Provide an example
39
40
The folder ``runestone/<component>/test/index.rst`` is a great place to add code
40
41
that demonstrates your new feature or component in action.
41
42
42
-
In fact you should provide two examples whenever possible to demonstrate that you can have
43
+
In fact you should provide two examples whenever possible to demonstrate that you can have
43
44
multiple instances of your component on a single web page.
0 commit comments