Developer Resource Allocation 2022

This page is a DRAFT work in progress -- it captures recent discussion, it is not Law. If you have feedback please let us know on the mailing list.

---

Like many open source projects, PortAudio is starved of developer resources. This page is an attempt to rationalize the limited availability of the maintainers, in particular Ross (@RossBencina) and Phil (@philburk).

Work Lifecycles

• Issues: Triage -> Development
• PRs: Progress to closure.

Issue and PR Triage (QoS: ideally, timely)

We understand that developers appreciate timely triage and investigation of their issues, and that being responsive helps make the most of conversations around new issues. We are aiming to spend time each fortnight on triage.

You can help reduce the triage load by asking non-issue questions on our mailing list. That's the place where knowledgeable users are likely to help you.

Issues:

Ross and Phil proceed in two phases:

1. First pass

   • Assign tags for code area and category
   • Assign initial priority
   • If necessary comment and ask obvious questions
   • Ping (@-mention) relevant specialists for comment
   • Close if possible

2. Investigate

   • Review/analyse relevant code
   • Subsequent comments/communication
   • Adjust priority

An investigation is complete when it is well understood what work needs to be done to resolve the issue. At that point it becomes "development," and is no longer in triage -- someone needs to do the work (see below).

PRs

Progress PR to: merge, request changes, or reject.

PRs should generally have an associated issue. If you are fixing a bug in a PR, please first file an issue describing the bug.

Development (QoS: best effort)

• Fix issues
• Write tests
• Write code
• Deep dive on mysterious bugs

Anyone can contribute to the discussion, development or submit a PR for any issue, irrespective of priority. Contributors please feel free to "scratch an itch" or "pick low hanging fruit."

Level of support

Below are proposed levels of support for different areas of the code base. Known maintainers are better documented here

level one "widely used, committed (if stretched) maintainers"
    host apis
        Mac -> ?Phil
        ASIO -> ?Ross
        DirectSound -> Ross
        WMME -> Ross
        WASAPI -> Dmitry
        skeleton -> Ross
        audioio -> user:alarixnia
    
    common code
        -> Ross, Phil
    
    tests/qa code
        -> Phil
       
    cmake build
        -> Be-ing
        
    ./configure build
        -> Phil, others
        
     legacy msvc build
        -> Ross
                   
level two "used but orphaned, no maintainer"
    host apis
        WDM/KS
        JACK
        ASLA
        
level three "no known users, no maintainer"
    host apis
        OSS
        ASIHPI (still alive, see ticket #444)

We would like to attract new contributors, both to pick up work on issues, and especially to act as maintainers for level two and level three code areas.

If your issue or PR is in a level one code area, you can expect Phil, Ross or Dmitry to make an effort to respond as appropriate. Otherwise, we may try to help, but we won't give your issue priority. In all cases, we would appreciate it if issue reporters could take a leading role in investigating and resolving the issues that they report.

Ross' and Phil's resource allocation

At the moment Ross and Phil meet virtually for about an hour each week (when possible) and are working on adopting the following alternating two-week cycle:

Week A:

• Triage issues
• Triage pull requests
• Progress/merge pull requests

Week B:

• Undertake development on high priority tickets. For the time being this means P0, P1, P2 only, in that order.