CONTRIBUTING

Contributing

When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.

For more info please visit our How to contribute with Accedo Build Confluence page to check how to reach us to discuss your proposal.

Pull Request Process

1. Create a branch with a descriptive name
2. Follow the commitlint commit message styling convention
3. Update all the module documentation. See the Documentation to include section
4. Version the module
5. Create the Pull Request to main (please review the details included in Pull Request Guidelines section)

Pull Request Guidelines

In order to create a good quality Pull request, it is required the following (this is automatically tested and PR will not be merged without it)

1. Add a descriptive and concise Pull request title (not the default one).
2. Add a descriptive and detailed Pull request body, including a Summary section.
3. Add at least one reviewer (default ones + any other you think that can/should review).

Versioning

We do not follow the SemVer version scheme, even if it must our versioning is compatible with it.

Meaning of the version numbers:

• major - Fixed to 4
• minor - Increased for breaking changes like API modifications
• patch - Increased for non breaking changes and fixes

Said that, all the module packages must be aligned with the packages/xdk-core module mayor and minor versions to ensure the compatibility.

Minor versions in the core package are related to XDK internal APIs and can introduce breaking changes

{
  ...
  "dependencies": {
    "@accedo/xdk-core": "~4.1.0",
    "@accedo/xdk-device-workstation": "~4.1.0",     // same minor version than xdk-core, will work
    "@accedo/xdk-device-samsung-tizen": "~4.0.0",   // different minor version than xdk-core, may break
    ...
  }
  ...
}

Package Creation

XDK follows a modular approach. Our rule of thumb to know how to split the modules is:

"If the module can be reused by other devices create it's own package, if not, keep into it's own device package"

-contrib packages

Remember that if you want to collaborate in a faster/simplier way, you can just create your module with the -contrib subfix and push your code.

This will tell us that this is a contribution and that the package can not be complete or fully compliant with our guidelines.

The Pull Request process will put the focus on the automatic validations and the included documentation rather than archiecture or code coverage.

Use this approach to share more pieces of the code between all the Accedo developers.

Naming convention

In the next example you can see the rules that we follow as naming convention:

const platform = 'Brand name, like LG or Hisense';
const model = 'OS name, like Tizen or AndroidTV';
const stack = 'SDK, Lib or API, like hls.js or video from html5 video';
const type = ['subtitles', 'audio', 'drm', 'ttl', 'new extension'];
const name = 'Generator name';

// yup, those are "folders" on a JS object to have syntax highlight
const packages = {
    // devices
    `xdk-device-${platform}-${model}`
    `xdk-device-hisense-opera-contrib`,
    `xdk-device-browser-html5/`,
    // players
    `xdk-player-${model}-${stack}`,
    `xdk-player-html5-video`,
    `xdk-player-html5-hlsjs-contrib`,
    // storage
    `xdk-storage-${model}-${stack}`,
    `xdk-storage-html5-localstorage`,
    // extensions
    `xdk-extension-${type}-${model}-${stack}`,
    `xdk-extension-subtitles-all-vtt-contrib`,
    `xdk-extension-tts-html5-tts`,
  },
  templates: {
    // generators
    `generator-xdk-${name}`
    `generator-xdk-dva`

  }

Documentation to include

In order to help the developers with what they can expect from the module please add the next files

• README.md -> Must includ a table with the supported capabilities and the XDK implemented ones
• KNOWN_ISSUES.md -> Must include any known issues for the current version and a historic by version.

Code of Conduct

In Accedo we have our own Accedo code of conduct that we must follow.

From the Build team we want also pledge

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.

Attribution

This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at http://contributor-covenant.org/version/1/4