Using GitHub

	This page has been deprecated.
	The information on this page are likely out-of-date and will not be updated in the forseeable future. It may be removed at any time.

Pull Requests

So, your pull request has been sitting on the Audacity pull request page for 22 months, the gestation time of an elephant, and even so Audacity has not pulled it yet. What's going on?

Communicate

Did you get one of these?

PLEASE READ this Fake Milestone

http://wiki.audacityteam.org/w/index.php?title=GitHub_Pull_Requests This isn't a milestone. It's a way to 
tell people making any decent sized pull requests to please come over talk with us at the audacity devel 
email list. If you just rely on the GitHub pull request messages, you may find we ignore or close the pull 
request for what does not seem to you to be a good reason. Please come and talk. Translators should subscribe 
to audacity translators email list instead. There is a bit more on our wiki about how we use these pull 
requests and the labels.

Most pull requests require communication. So come and talk with us.

Work Multipliers

New Platforms and Libraries

You did get in contact with us via audacity-devel email. Why then did we then turn down your pull requests? Why wouldn't we accept changes that make Audacity also work on both an Atari 1040STF, and on SuSE too? After all, a pull request is easy to just pull into head, and it could be of use to people on those platforms.

Well, the short answer is that each new platform is a work multiplier for us. We already support three platforms, Windows, Mac and Debian Linux. These 'three platforms' are already more like seven. We have users on with Windows 7, 8, 10, Mac El Capitan, Sierra, High Sierra, and various flavours of Ubuntu. Users don't always upgrade to the latest and shiniest new machines - and so we can't just target the very latest.

If we were to support Atari 1040STF and SuSE, we would have ongoing continuous work to maintain those platforms. Possibly we don't even have an Atari or a SuSE machine. Emulators only ever approximate. Your pull request isn't just a once off. From your perspective we've far less to do than you already did. We just pull the request that you have put together and got working. From ours perspective though, each new platform IS a big chunk of work. New platforms are ongoing work that continues from the day we decide to support that platform. So our policy on new platforms is that we ARE interested, and if YOU are interested enough to join in and support and maintain for that platform then we may well take your changes, and offer that platform for as long as you stay.

There's a very similar story for features that integrate new libraries. Typically a new library is a big step for us. If you turn out to be a fly-by, we end up maintaining something that was not core to what we do. We'd probably encourage you to make the addition that needs a new library as a plug-in. Then if you don't maintain it going forward, and if it starts to bit-rot, we can drop the plug-in and the library without damaging Audacity. However, if it's tightly woven into Audacity, then we don't have that option.

Review comments

who reviews?

Breaking The Build

Travis.

GitHub Issue Tracker

We don't use it.

Instead we track bugs in our own Bugzilla.

GitHub Project Boards

We don't use them.

Instead we plan features in this wiki. We're not corporate. We don't follow the corporate model of a plan that everyone agrees to. How could we have a project board that sets out what we have agreed as the corporate plan and priorities? It's more personal than that.

Instead we have individual proposed projects, often with one enthusiast championing the project, often with some code already written/prototyped. We solicit feedback on ideas and plans from others in Audacity. But the guiding principle is still DOER DECIDES. A good doer though takes account of feedback. In an Open Source project, we have to be wary of back-seat drivers. We most need the people who actually contribute, so we optimise for them.