Skip to content

Internal contribution guide

Jump to bottom
Mateusz Front edited this page Jul 28, 2020 · 20 revisions

General rules

Here are a couple of points to remember when starting development in Membrane:

  • The task author is responsible for watching over it:

    • asking for needed resources/explanation/help
    • keeping it in the proper place in the kanban
    • assigning reviewers and making sure they remember about the review
    • merging pull requests
    • transferring the task to someone else if necessary.

  • When moving a task from "Backlog" to "To do" replace any notes with an issue in the proper repo and assign yourself.

  • Create a branch with a meaningful name

  • You can open a draft PR right away.

  • Remember to link the issue to the PR (either by adding Closes # and PR number or using the UI)

  • Try to avoid making huge PRs - if the feature you're working on is big, create draft PR with a list of steps and ask for a review as early as possible. You can create smaller PRs from sub-task branches and use the main as master for this feature

  • Before requesting review generate docs and check if there are only modules or functions that are part of API there, they have specs and docs, there are no dead links nor out-of-date content etc. It's worth doing even if you didn't change the docs. Do the same when reviewing someone else's PR.

  • When finished, make a self-review before assigning a reviewer.

  • Assign a reviewer. Ask during the stand-up meeting who can do the review. You need at least one approval from one of the core team members and passing CI tests to merge new features.

  • When reviewer requests fixes, refer to each comment in at least one of the following ways:

    • Fix the problem and add a 'done' reply if GitHub doesn't mark it as 'outdated'.
    • Start a discussion or ask for an explanation in a reply.
    • If a comment requests new, big features, suggest moving that to a separate PR. Remember to create an issue for that and pin it to the proper column in the kanban.

    Remember to watch for comments accidentally marked as outdated and don't mark someone else's comments as resolved.

  • When you consider all the comments fixed, re-request the review.

  • Do not force push changes to the reviewed commits - this breaks 'changes since last review' functionality on GH

  • Always remove your branch after merging the PR. It should happen automatically. If not, enable that in settings (or ask someone with permissions to do this)

Creating new plugin/repo

  • Each new plugin should have its own repo and hex package
  • The plugin should contain one or more elements related to the same format/protocol (e.g. H264 plugin may contain decoder, encoder and parser)
  • One plugin should only depend on at most one native library, so if you need separate libraries for decoder and encoder each should be a separate plugin
  • When starting development you should create new repo based on https://github.com/membraneframework/membrane_template_plugin, enable CI and create a branch (often called develop) and follow the usual steps.
Clone this wiki locally