1. Home
  2. OCaml Meetings
  3. User & Developers Meetings
  4. 2014
  5. Github Pull Requests for OCaml development
  • en

Github Pull Requests for OCaml development: a field report

Gabriel Scherer (INRIA)

On 2014/01/30, we started an experiment allowing users to submit and discussion patches to the OCaml distribution on its Github mirror rather than through the existing Mantis bugtracking system. The experiment is time-bounded and the decision is due to be revisited in late July. The main goal of the experiment is to evaluate whether Github makes maintainers life easier, by streamlining the patch submission and review process and, in particular, encouraging non-maintainers to participate in the patch evaluation process. There were also claims of usability benefits for the patch submitters themselves, and the more subjective aspect of sending a signal that the development is more open that sometimes perceived.

The OCaml Workshop would be an excellent place to present an analysis of this experiment, as it happens shortly (in summer-vacation time) after the announced bound, and its audience is precisely the people that already did or could get evolved in occasional contributions to the OCaml distribution (as a subset of the larger OCaml ecosystem).

If this proposal is accepted, I plan to collect, synthesize and present data in several distinct and complementary forms:

(1) Raw numbers: can we observe a significant change in contribution habits (patch submission and patch review) sparkled by the experiment?

(2) Collected user stories: what is the subjective perception of the various people that interacted with the Github interface?

(3) Manual classification: which form of contributor interaction were observed? What are is a broad categorization of the patches sent (in nature, and in how they got handled through the review process)? Is there any difference from the Mantis statu quo?

Raw numbers are easy to misinterpret (for example, there probably is a running trend of increased activity since 4.00.0 that we should be careful to separate from Github specifics); but user stories and content classification could help form a more robust view of the development process.