Skip to content
Sean DuBois edited this page Dec 4, 2018 · 24 revisions

Contributing

Thank you very much for contributing pion-WebRTC! This project only exists because of the work of individuals.

Creating an issue

Feel free to submit bugs and feature requests to the issue tracker. If you believe something will lead to a discussion sign up for the Golang Slack and join the #pion channel. It is much easier to debug/discuss with the shorter feedback loop.

You can also use our mailing list we use this for longer discussions to give others time to respond.

Contributing Code

Thank you for contributing! Every PR is different, but here are some high level rules that should help make it a success. This isn't an exhaustive list, but these are some bullet points that should help make contributing easy.

  • When writing your code consider the users first, pion-WebRTC is only as good as what people can build with it!
    • Try to conform to the WebRTC JS API as closely as possible. Users should be able to use API without even reading the docs.
    • Should be actionable. Many parts of the WebRTC API don't apply to our use cases, use your best judgement.
    • If you are creating something new, create an example to demo it and help users explore it quickly!
    • Separate into reusable modules so others can easily read and reuse your work.
  • Install the commit message hook ln -r -s .github/lint-commit-message.sh .git/hooks/commit-msg
    • This is tested in CI, the rules are available here
  • Create your PR early. Even if the code isn't complete this gives others the chance to know your working on it.
  • Make sure all the linters and checks pass, for extra credit try to even raise the code coverage!

Once your PR is ready you just need one review by a pion-WebRTC developer, then you can merge to master. To become a pion-WebRTC developer you need to just have one PR merged to master.

Project Ideas

All the following projects are currently unowned, so feel free to work on anything here! If you do start on something please reach out so we can remove it from the list

Logging API

Currently pion-WebRTC is inconsistent about its logging, we just use the fmt package and don't have any levels.

Someone needs to look at other libraries and find the idiomatic way to implement logging. Do we implement levels, do we allow people to pass their own logger implementation?

Enable disabled linters

Some of our linters are turned off because the effort to fix the issues was too high at the time, turning them on here and fixing them in a PR would be a huge help for code quality.

Public Website

Start a public website build with hugo. It would be a nice way for us to quickly communicate what pion-WebRTC is, projects that use it and try to get people excited about it.

It should just be hosted on gh-pages, and we can get a domain to redirect to it. Would also like to move our jsfiddles to this instead, so we can control how that all works.

Build a media server powered by pion-WebRTC

Start a thread on the mailing list and get feedback around this. Building a media server could enable a lot of people to build cool things.

I am not sure what the feature set would be, but it is only worth doing if we can do something different/interesting then existing projects.

Helping Community Projects

There are lots of interesting projects that pion-WebRTC could be used with, these are just some of them. Feel free to add more!

Mobile Support

Currently it isn't possible to cross-compile pion-WebRTC for mobile. Implementing this would open up a lot of interesting possibilities

Add commit message formatting rules, and git hooks to enforce them

Add an example of pion-WebRTC <-> pion-WebRTC

Add e2e tests of pion-WebRTC <-> pion-WebRTC

Add e2e tests of pion-WebRTC <-> Chromium

Handle RTP packet loss

We currently don't handle RTP packet loss either way, implementing both would be really interesting

  • Add inbound/outbound RTP jitterbuffers that emit/handle NACKs
  • Grow/Shrink the latency dynamically
  • Add a output/graphs so users can debug their packet loss

Improve ICE

Currently our ICE implementation is very naive, these are the things that need to get better

  • Support ICE-lite peers
  • Choose the best peer, not just the first that arrives (measure RTT etc..)
  • Actually assert the validity of incoming packets (right now we only check that the packet comes from the right IP)

Separate the stack into reusable modules

WebRTC is made up of many distinct technologies, which can be seen here

We have implemented a lot of these things and most of these components deserve their own package. Create a plan to seperate these things out, we should not lose any development speed and still have all the CI we have now.