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: .github/pull_request_template.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,11 +21,12 @@ However, reviewers may request that you complete any actions in this list if you
21
21
22
22
-[ ] My PR is **created against the `main` branch** of code (unless it is a backport or is fixing an issue specific to an older branch).
23
23
-[ ] My PR is **small in size** (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
24
+
-[ ] My PR **follows all coding best practices** based on the [Code Conventions Guide](../CODE_CONVENTIONS.md)
24
25
-[ ] My PR **passes [ESLint](https://eslint.org/)** validation using `npm run lint`
25
26
-[ ] My PR **doesn't introduce circular dependencies** (verified via `npm run check-circ-deps`)
26
27
-[ ] My PR **includes [TypeDoc](https://typedoc.org/) comments** for _all new (or modified) public methods and classes_. It also includes TypeDoc for large or complex private methods.
27
28
-[ ] My PR **passes all specs/tests and includes new/updated specs or tests** based on the [Code Testing Guide](https://wiki.lyrasis.org/display/DSPACE/Code+Testing+Guide).
28
-
-[ ] My PR **aligns with [Accessibility guidelines](https://wiki.lyrasis.org/display/DSDOC9x/Accessibility)** if it makes changes to the user interface.
29
+
-[ ] My PR **aligns with [Accessibility guidelines](https://wiki.lyrasis.org/spaces/DSDOC10x/pages/408944958/Accessibility)** if it makes changes to the user interface.
29
30
-[ ] My PR **uses i18n (internationalization) keys** instead of hardcoded English text, to allow for translations.
30
31
-[ ] My PR **includes details on how to test it**. I've provided clear instructions to reviewers on how to successfully test this fix or feature.
31
32
-[ ] If my PR includes new libraries/dependencies (in `package.json`), I've made sure their licenses align with the [DSpace BSD License](https://github.com/DSpace/DSpace/blob/main/LICENSE) based on the [Licensing of Contributions](https://wiki.lyrasis.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-LicensingofContributions) documentation.
DSpace has established coding conventions or best practices that all contributions must follow in order
4
+
to be accepted.
5
+
6
+
These code conventions describe the best practices for design and implementation of DSpace code, helping ensure that all DSpace components have a consistent layout and follow the essential Web Content Accessibility Guidelines ([WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/)).
7
+
The best practices for formatting your code are defined in our separate [Code Style Guidelines](CODE_STYLE.md).
8
+
9
+
For additional guidelines, see the wiki documentation for [User Interface Design Principles & Accessibility](https://wiki.lyrasis.org/spaces/DSDOC10x/pages/408945765/User+Interface+Design+Principles+Accessibility).
10
+
11
+
1.[Enforcement of Guidelines](#enforcement-of-guidelines)
12
+
2.[Angular Guidelines](#angular-guidelines)
13
+
1.[Templates in Base Theme should only use default Bootstrap styling](#templates-in-base-theme-should-only-use-default-Bootstrap-styling)
14
+
2.[Required Bootstrap Components must use `ng-bootstrap` library](#required-bootstrap-components-must-use-ng-bootstrap-library)
15
+
3.[Document methods and classes using TypeDoc](#document-methods-and-classes-using-typedoc)
Enforcement of these code conventions is handled in two ways:
22
+
* Some guidelines are enforced strictly via static code tools such as ESLint. Where possible, we prefer to automate enforcement.
23
+
* All guidelines are enforced during code review by the assigned reviewers.
24
+
25
+
## Angular Guidelines
26
+
27
+
### Templates in Base Theme should only use default Bootstrap styling
28
+
29
+
All templates in the Base Theme ([/src/app](/src/app) directories) should only use default Bootstrap styling. Documentation at: https://getbootstrap.com/docs/4.6/getting-started/introduction/
30
+
* Exceptions may be made for accessibility purposes. For example, Bootstrap notes their [default color scheme does not always have sufficient color contrast](https://getbootstrap.com/docs/4.0/getting-started/accessibility/#color-contrast).
31
+
32
+
### Required Bootstrap Components must use `ng-bootstrap` library
33
+
34
+
When Bootstrap Components (accordion, dropdown, etc …) are required you MUST use the included `ng-bootstrap` library. Documentation at: https://ng-bootstrap.github.io/#/components/accordion/examples
35
+
36
+
### Document methods and classes using TypeDoc
37
+
38
+
Write [TypeDoc](https://typedoc.org/) comments for all new (or modified) public methods and classes, as well as for large or complex private methods.
39
+
40
+
41
+
## Accessibility Guidelines
42
+
43
+
The DSpace User Interface strives to align with [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/) AA criteria. Some AAA criteria may also be supported. For more information see [Accessibility documentation](https://wiki.lyrasis.org/spaces/DSDOC10x/pages/408944958/Accessibility).
44
+
45
+
The use of the Bootstrap framework can help in achieving some WCAG goals such as ‘Visual Presentation’ (AAA), 'Parsing' (A), ‘Orientation’ (AA), ‘Reflow’ (AA) and ‘Text Spacing’ (AA). See the Bootstrap chapter ["Accessibility"](https://getbootstrap.com/docs/4.0/getting-started/accessibility/) for an explanation of WCAG and where to find additional information.
DSpace has established code style / code formatting guidelines that all contributions must follow in order
4
+
to be accepted.
5
+
6
+
These code style guidelines describe the best practices for formatting your code. The best practices for design and implementation of your code are defined in our separate [Code Conventions](CODE_CONVENTIONS.md).
7
+
8
+
*[Enforcement of Guidelines](#enforcement-of-guidelines)
Enforcement is handled by [ESLint](https://eslint.org/) using the configuration file in the root source directory: [.eslintrc.json](.eslintrc.json).
17
+
18
+
If you would like to pre-check your Pull Request for any Code Style issues, you can do so by running:
19
+
20
+
```
21
+
npm run lint
22
+
```
23
+
24
+
Code contributions may only suppress these rules if pre-approved. Code may suppress these rules by using [ESLint configuration comments](https://eslint.org/docs/latest/use/configure/rules#use-configuration-comments-1), for example `/* eslint-disable [rule-name] */`.
25
+
26
+
The DSpace TypeScript Style Guide is enforced on all Pull Requests to the "main" branch in `dspace-angular`. Therefore, if a Pull Request to the "main" branch does not align with the Style Guide, it will fail the build process within our GitHub CI.
27
+
28
+
## TypeScript Style Guide
29
+
30
+
For the DSpace Angular UI (written in TypeScript), we use [ESLint](https://eslint.org/) to validate the style of all Typescript (*.ts) files.
31
+
All style rules are defined in [.eslintrc.json](.eslintrc.json).
32
+
33
+
## Angular Style Guide
34
+
35
+
Follow the [official Angular style guide](https://angular.dev/style-guide). It contains guidelines for naming files, directory structure, etc.
36
+
37
+
## IDE Support
38
+
39
+
Most IDEs include an ESLint plugin which can automatically enforce the defined style rules in your Typescript code.
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+5-13Lines changed: 5 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,18 +12,10 @@ DSpace is a community built and supported project. We do not have a centralized
12
12
We accept [GitHub Pull Requests (PRs)](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork) at any time from anyone.
13
13
Contributors to each release are recognized in our [Release Notes](https://wiki.lyrasis.org/display/DSDOC9x/Release+Notes).
14
14
15
-
Code Contribution Checklist
16
-
-[ ] PRs _should_ be smaller in size (ideally less than 1,000 lines of code, not including comments & tests)
17
-
-[ ] PRs **must** pass [ESLint](https://eslint.org/) validation using `yarn lint`
18
-
-[ ] PRs **must** not introduce circular dependencies (verified via `yarn check-circ-deps`)
19
-
-[ ] PRs **must** include [TypeDoc](https://typedoc.org/) comments for _all new (or modified) public methods and classes_. Large or complex private methods should also have TypeDoc.
20
-
-[ ] PRs **must** pass all automated pecs/tests and includes new/updated specs or tests based on the [Code Testing Guide](https://wiki.lyrasis.org/display/DSPACE/Code+Testing+Guide).
21
-
-[ ] User interface changes **must** align with [Accessibility guidelines](https://wiki.lyrasis.org/display/DSDOC9x/Accessibility)
22
-
-[ ] PRs **must** use i18n (internationalization) keys instead of hardcoded English text, to allow for translations.
23
-
-[ ] Details on how to test the PR **must** be provided. Reviewers must be aware of any steps they need to take to successfully test your fix or feature.
24
-
-[ ] If a PR includes new libraries/dependencies (in `package.json`), then their software licenses **must** align with the [DSpace BSD License](https://github.com/DSpace/dspace-angular/blob/main/LICENSE) based on the [Licensing of Contributions](https://wiki.lyrasis.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-LicensingofContributions) documentation.
25
-
-[ ] Basic technical documentation _should_ be provided for any new features or configuration, either in the PR itself or in the DSpace Wiki documentation.
26
-
-[ ] If a PR fixes an issue ticket, please [link them together](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue).
15
+
We provide a [Code Contribution Checklist in our Pull Request Template](https://github.com/DSpace/dspace-angular/blob/main/.github/pull_request_template.md#checklist) which includes guidance
16
+
on things we will look for in your PR.
17
+
18
+
We also provide a [Code Style Guide](CODE_STYLE.md) (detailing how to format your code) and a [Code Conventions Guide](CODE_CONVENTIONS.md) (detailing established coding best practices).
27
19
28
20
Additional details on the code contribution process can be found in our [Code Contribution Guidelines](https://wiki.lyrasis.org/display/DSPACE/Code+Contribution+Guidelines)
29
21
@@ -37,7 +29,7 @@ Once you have an account setup, contact @tdonohue (via [Slack](https://wiki.lyra
37
29
## Help others on mailing lists or Slack
38
30
39
31
DSpace has our own [Slack](https://wiki.lyrasis.org/display/DSPACE/Slack) community and [Mailing Lists](https://wiki.lyrasis.org/display/DSPACE/Mailing+Lists) where discussions take place and questions are answered.
40
-
Anyone is welcome to join and help others. We just ask you to follow our [Code of Conduct](https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx) (adopted via Lyrasis).
32
+
Anyone is welcome to join and help others. We just ask you to follow our [Code of Conduct](https://lyrasis.org/code-of-conduct/) (adopted via Lyrasis).
On our wiki, you may also find a [list of all past releases, including their current levels of support](https://wiki.lyrasis.org/spaces/DSPACE/pages/69010426/Releases).
28
+
27
29
28
30
## Documentation / Installation
29
31
30
32
Documentation for each release may be viewed online or downloaded via our [Documentation Wiki](https://wiki.lyrasis.org/display/DSDOC/).
31
33
32
34
The latest DSpace Installation instructions are available at:
0 commit comments