Jump to content

New BOSS projects: Difference between revisions

From Bath Wiki
cat
Non-functional: add boss hosting guide
 
(2 intermediate revisions by the same user not shown)
Line 29: Line 29:
* All systems must comply with our [[BOSS data collection policy|data collection]] and [[BOSS security policy|security policies]].
* All systems must comply with our [[BOSS data collection policy|data collection]] and [[BOSS security policy|security policies]].
* If an admin account is required for some parts, please use [[auth.bathcs.com]] to validate the user
* If an admin account is required for some parts, please use [[auth.bathcs.com]] to validate the user
* Follow the design principles in [[BOSS/Design|our design page]]
* All data input should be validated on the backend (not just the frontend)
* All data input should be validated on the backend (not just the frontend)


=== Non-functional ===
=== Non-functional ===


* Keep It Simple Stupid: do not add any features that are not needed; do not use a fancy programming language that is not needed; do not collect data that is not needed.
* Where practical, use an existing open source library, rather than building your own. This is because students don’t have much time and don’t want to be managing a completely new system.
* Include credits for who wrote it and contact details once you leave the University.
* Include credits for who wrote it and contact details once you leave the University.
* Hosting needs to be free, and preferably on-premises (we will not get any consistent funding)
* Hosting needs to be free. See the [[Hosting BOSS projects]] guide.
* Webpages should be light and fast to load (so we support all type of devices)
* Webpages should be light and fast to load (so we support all type of devices)
* A webpage should work on mobile (because students are lazy).
* A webpage should work on mobile (because students are lazy).
* The main branch should be protected (except for mirrors)
* The main branch should be protected (except for mirrors)
* Get someone to review your code (this helps with not having any security issues)
* Get someone to review your code (this helps with not having any security issues)
* Code follows relevant [[Programming language guidelines]]
* Code follows relevant [[Programming language guidelines]] and the style of the language used. If you try to go against the style of the programming language, you will find more barriers and have to implement hacky workarounds which will lead to unreadable, confusing and buggy code.
* The project must be deployable with Docker for security reasons.
* Documentation should be included to setup a development environment as well as production
* Documentation should be included to setup a development environment as well as production
[[Category:Bath Open Source Society]]
[[Category:Bath Open Source Society]]

Latest revision as of 08:16, 26 August 2026

BOSS want to encourage all students to contribute to our Bath GitLab organisation, either by improving our current systems or adding a project to the organisation, which then we can potentially host on the bathcs.com domain.

Mirroring

Due to some projects’ complexity and the fact that original author may want to use their code to gain respect on GitHub or use it for jobs, we allow people to just mirror their project into the organisation.

However we do require the project to be stored in the organisation for maintainability and future reference.

If you are mirroring, please make sure that the current version on the GitHub is the version which is hosted on bathcs.com or is currently used. The project description on Bath GitLab must link to the canonical (original) source code.

Licensing

Please see license policy for information on how our projects are licensed.

To summarise, new projects should be licensed under Apache-2.0 WITH LLVM-Exception, contributors must agree to the Developers Certificate of Origin (DCO), and any contributions must not violate the University of Bath’s Intellectual Property policy.

Requirements

Due to most projects being tested by chaotic Computer Science students as well as hosted publicly, we have a strict set of requirements for projects and things which need to be considered.

More requirements are hidden within the pages in this wiki, so please make sure to read any relevant pages. Hopefully we have made this at least somewhat entertaining to read or at least easy to skim.

To consider

  • Hand over procedure: Is there anything which cannot be handed over by our current procedures, if so how will we amend this?

Functional

  • All systems must comply with our data collection and security policies.
  • If an admin account is required for some parts, please use auth.bathcs.com to validate the user
  • All data input should be validated on the backend (not just the frontend)

Non-functional

  • Keep It Simple Stupid: do not add any features that are not needed; do not use a fancy programming language that is not needed; do not collect data that is not needed.
  • Where practical, use an existing open source library, rather than building your own. This is because students don’t have much time and don’t want to be managing a completely new system.
  • Include credits for who wrote it and contact details once you leave the University.
  • Hosting needs to be free. See the Hosting BOSS projects guide.
  • Webpages should be light and fast to load (so we support all type of devices)
  • A webpage should work on mobile (because students are lazy).
  • The main branch should be protected (except for mirrors)
  • Get someone to review your code (this helps with not having any security issues)
  • Code follows relevant Programming language guidelines and the style of the language used. If you try to go against the style of the programming language, you will find more barriers and have to implement hacky workarounds which will lead to unreadable, confusing and buggy code.
  • The project must be deployable with Docker for security reasons.
  • Documentation should be included to setup a development environment as well as production