-
Notifications
You must be signed in to change notification settings - Fork 440
Documentation and Communication
We have three main channels for documenting and communicating any relevant information about OBS : the official documentation, the GitHub's wiki and the blog.
Here are some tips about the appropriate way to write in those channels.
https://openbuildservice.org/help
This is the official documentation where we explain all the functionalities and workflows provided by OBS.
The goal is to teach users and administrators how to use the application.
Readers: experienced and inexperienced users, and administrators of OBS.
Tips:
- Use the highest level of abstraction possible
- Give detailed explanations about functionalities and workflows
- Avoid giving implementation details
- Use a language that any new user, with a technical background, can understand
- Add usage examples when possible
- Images and workflow diagrams can be helpful
https://github.com/openSUSE/open-build-service/wiki
In GitHub wiki pages, we can find the information that is relevant to developers and contributors: how to configure the development environment, how to deploy, architectural decisions, best practices, etc...
Avoid using other solutions like Etherpad, since it's hard to find documents again and we want to rely on a single solution.
Readers: current/future developers, and contributors with a technical background.
Tips:
- Use a low level of abstraction
- Go straight to the point
- Give implementation details
- Add links to relevant parts of the code, technical articles or talks
https://openbuildservice.org/blog
The blog is mainly used to communicate news about OBS. We publish blog posts periodically about meaningful improvements and new features.
We also use the blog to write how-tos about new features in the beta program, so interested users can start testing them. Those features are work-in-progress, so we don't write official documentation about them until we release the final version.
Readers: OBS users.
Tips:
- Use a medium/high level of abstraction
- Go straight to the point
- Avoid giving implementation details
- Add relative links to other blog posts related to the topic
- Start with a lede, an initial paragraph describing briefly who, what, where, when, why, and how.
- Be concise: use short sentences, short paragraphs, and short overall messages.
- Use simple words.
- Use active voice.
- Make it easy to skim: use several headings and subheadings, create bulleted and numbered lists, include images, etc...
- Development Environment Overview
- Development Environment Tips & Tricks
- Spec-Tips
- Code Style
- Rubocop
- Testing with VCR
- Authentication
- Authorization
- Autocomplete
- BS Requests
- Events
- ProjectLog
- Notifications
- Feature Toggles
- Build Results
- Attrib classes
- Flags
- The BackendPackage Cache
- Maintenance classes
- Cloud uploader
- Delayed Jobs
- Staging Workflow
- StatusHistory
- OBS API
- Owner Search
- Search
- Links
- Distributions
- Repository
- Data Migrations
- next_rails
- Ruby Update
- Rails Profiling
- Installing a local LDAP-server
- Remote Pairing Setup Guide
- Factory Dashboard
- osc
- Setup an OBS Development Environment on macOS
- Run OpenQA smoketest locally
- Responsive Guidelines
- Importing database dumps
- Problem Statement & Solution
- Kickoff New Stuff
- New Swagger API doc
- Documentation and Communication
- GitHub Actions
- How to Introduce Software Design Patterns
- Query Objects
- Services
- View Components
- RFC: Core Components
- RFC: Decorator Pattern
- RFC: Backend models