Hi Shaun,
Thanks for the additional details you provided on the issue and PR. I have summarized the current situation in comments on the issue and the PR:
In short, we’re hoping to get this merged at our next meeting.
I see that this relatively simple change stalled for a while, and it was unclear to the participants why this happened. Having just read through the comment history and thinking this through, here are a few suggestions and observations that might help other contributors in the future:
- In issues and PRs, clearly describe why any change or feature is needed, not just from the perspective of the contributor but from that of other users of OTP. These days we try to be very deliberate about what features are added, considering the ongoing long-term effort of maintenance and coordination. It is always an option to have unusual or special-purpose features in your own branch of OTP; features added to the main OTP repo should be of more general interest. On the other hand, no real justification is needed for “sandbox” contributions, which will be merged with cursory review as long as they are isolated as described in the documentation.
http://docs.opentripplanner.org/en/latest/SandboxExtension/
- Always clearly describe or distinguish between OTP 1.x and 2.x in issues and pull requests. Describe whether your changes or problems apply to one or both of these branches. It’s not essential to consider OTP 1.x if you are only contributing to the current 2.x codebase. But we will need to verify whether any 1.x contributions can be ported over to 2.x and whether they are relevant in 2.x. Ideally the contributor will do this research and explain the situation in the issue/PR.
- Changes to OTP 1.x will not be prioritized. No further 1.x releases are planned, so (with possible rare exceptions) the 1.x-dev branch is expected to receive only critical bugfixes and not new features. The core OTP development team must generally respect the priority of their employers and clients, which is OTP 2.x.
- Always provide a prominent link from PR to the issue it solves, ideally in the first comment on that PR (the PR description or even title). Please provide concise, clear descriptions of issues or solutions even if it seems a little repetitive (restating the same thing on one or more issues or PRs that are related). Developers often have to juggle hundreds of tickets from multiple projects (OTP may not even be their primary project) and these bits of extra information can make this process much smoother.
- Development resources (i.e. software developer time) are limited. The people reviewing and managing issues are employees or contractors of agencies and companies with their own commercial or public service objectives. We have follow these priorities and realistically not everything is going to get done. These organizations want the OTP community to thrive, but can only spend so much time and money on that broader goal. The overhead of project management, architecture, and governance are significant. Organizations expecting to contribute nontrivial changes should expect to devote significant time to discussions, meetings, and issue management, not just writing code.
- A culture has emerged of seeking consensus on any new changes or features and subjecting them to critique by other developers. This has been happening primarily in our twice-weekly developer meetings (video/audio calls). Experience shows that the consensus/critique/finalization process goes much faster and much more smoothly in this context, compared to email and text comments. Almost all PRs merged recently were debated, revised, and merged during these meetings. If possible, join one of the developer meetings. This will get eyes on your issue or PR immediately, and resolve any questions immediately to unblock progress. The meeting times might not be good depending on where you're located - in that case, if progress seems slow, please try to set up an earlier or later call with whoever is reviewing your issue.
- It’s August, and in the high latitudes of the northern hemisphere (where a lot of OTP developers are currently located) this is vacation season. Around this time of year (as well as the second half of December), it is possible that development activity or communications will slow significantly or even halt.
I will try to pull these and some other recent suggestions into a CONTRIBUTING file in the OTP repository, which Github will make visible to all new contributors.
Thanks,
Andrew