Hi Everyone,
I am writing to give a bump to some of what was written in reply to
Andrew's thread on auto-creating JIRAs. I would like to try to focus on
small (hopefully) short term achievable items, to make the community
friendlier to newcomers and reduce toil for regular contributors.
1. I think creating a GitHub action that can automatically copy a GitHub
issue to a JIRA, close the issue and leave a note [1] would be useful.
The intent is to be friendlier to people interacting with the project for
the first time and letting them decide how invested they are in a bug to
create the necessary credentials to track it.
2. Guidelines for trivial/minor patches (those not requiring a JIRA) and
updating the PR tool to accept a title indicating them as such. I would
propose the following fall under the trivial guideline:
a. Grammar, usage and spelling fixes that affect no more than N files
b. Documentation updates affecting no more than N files and not more
than M words.
3. Guidelines for when to use the auto-create JIRA tool:
a. Refactors (no functionality change) affect no more than N [2]
files. If coding work required on the code is less than 1 or 2 hours,
JIRAs can be disruptive enough to one's workflow and don't really
contribute to the "openness" of the project in a meaningful way. This can
be a slippery slope, but I think we can all be judicious on when to use it.
b. Small one-off bug fixes by new contributors to the project (ideally
this would be accompanied with a note pointing to the contributors guide).
4. IIUC some of the angst on the thread from regular contributors was the
amount of duplication of effort it is to fill in details in multiple
places. However, I do think transparent development is important and
migration away from our current tooling would be an expensive investment.
In my mind JIRA serves as a useful index of issues/feature backlog that is
tied into our development and release tooling. I'm not sure it falls
within the "Apache Way" but it seems that as long as the necessary
discussion has already happened on list (possibly by way of reviewing
PRs/Google Docs and summarizing them back in the list) then minimal JIRAs
are sufficient (i.e. Title, Component, and a link to the discussed
artifact).
So for instance if we had an RFC process for a major feature I would
imagine the guideline would be something like:
a. Create JIRA for writing RFC (should be fairly minimal, I imagine
most content will actually go into a PR for the RFC). This gives others
that might be interested in the area knowledge that one is being written
and an opportunity to collaborate ahead of time.
b. Send RFC for review and give a heads up to the mailing list.
c. Gain consensus on RFC
d. Create minimal JIRAs corresponding to work items to complete the RFC
and link back to it.
For less involved features I still think minimal JIRAs are still OK, if
other contributors/observers have particular concerns they can ask for more
details.
For me the key is expressing intent up-front to enable potential
collaboration, discussion and feedback before a lot of time is invested.
After the fact, understanding the rationale that went into decisions is
also useful.
Thoughts? Anything other guidelines or norms we should try to socialize
around our development process?
Thanks,
Micah
[1] A note like: "This issue has been copied to JIRA item [ARROW-11111].
If you wish to discuss or further track it please track it there. For more
details please see the [contributors guide](
https://arrow.apache.org/docs/developers/contributing.html)"
[2] I used N above because I think it is best to treat the number as a
guideline rather than a rule. But I would pick N=2 if we wanted to force
the rule.
