Hi Antoine,
Can you expand a bit on this? In particular, which aspects of using
> JIRA feel bureaucratic? Is it the requirement to create a new issue
> for each PR? Or is it other concerns (such as the UI for entering or
> searching issues)?
>
First of all, thank you for taking my concerns and actively trying to
understand them.
It is advantageous for everyone to have small, focused PRs, as they are
easy to review and can narrow the discussion to a single problem. This also
makes it easy for new contributors to start. For this to work, we need a
system on which the work needed to create and merge PRs must be small in
absolute terms, as the "meat" of the PR may be small. *This* IMO is not
working. As a flavour, below is the usual process for a situation on which
while working on an issue, I found a side issue and need for PR it:
1. create the PR on github with the fix
2. got an email from github that a bot commented that I must put the JIRA
issue. Got it, I forgot about that...
3. go to JIRA, if not logged in, log in (3 clicks + some password manager
stuff, and be redirected to a random page)
4. press "create issue"
5. Fill content:
* type
* Summary (do not forget to add the component to the title)
* component
* assign myself
* description(*)
6. press create. A small popup on JIRA will show that it was created. It is
really difficult to copy-paste the issue number from the pop up:
7. Press on it before it disappears so that I can easily copy-paste its
number. I need to be fast, though: if it disappears before I press on it, I
will need to find it, which is a story on itself.
8. go back to github and modify the title
(*) I already wrote a description on the PR using markdown, which is when I
was first thinking about the PR itself. JIRA does not support markdown, so
I can't copy-paste. I now need to fight with the "visual" editor, or
remember what the notation is for the text. I also need to remember that
{{{ }}}, not backticks, is for code. I will likely leave that one empty.
I am adding hiccups above because they do happen due to the mental workload
involved, even for someone quite proficient at this.
Let's now assume that all is done and we can merge it. Let's assume for
simplicity that the PR was done by a contributor that is already a member
of JIRA and already has a contributor role on JIRA (the easy case).
1. Open a terminal and navigate to a clone of the arrow project that
already has a Python venv on it
2. run `source venv/bin/activate` (our script has some external
requirements, thus we need this)
3. run `dev/merge_pr.py PR number`. What was the PR number again?
4. Go to github and copy the PR number
5. paste on the terminal and press enter
6. Now type my username from JIRA
7. Now my password. I store all my passwords on a password manager with a
browser extension and often work from different VMs via ssh. Thus, I go to
JIRA on the browser, click on the extension and copy password
8. paste on my terminal and press enter
9. Assuming that no conflicts arise, press enter/yes 2 or 3 times and it is
merged and pushed. Great!
10. When updating the JIRA issue, I noticed on the terminal that the
component is missing. Dam...
11. press on the JIRA link on the terminal (and a possible new login) and
add the necessary components
12. press enter on the terminal. Now we are done.
13. Go to github and thank the contributor for the great work.
IMO, these flows are large. They represent about the same time I would need
to create the small fix, a test, and PR it, including the PR description.
Maybe some people have better flows than I do, but my understanding from
other committers is that these steps are more or less representative of a
good day (i.e. no merge conflicts, master passing, etc).
A corollary problem is that this is not something only on committers /
PMCs' plate. Let's now go through the other side: I am a brand new
contributor.
1. create the PR on github because I found something to fix and fixed it
2. got an email by a bot that I must follow some convention.
3. okk, let me try to fix the title. Oh, I need an issue in JIRA...
3. go to JIRA and there is no "create issue" option...
4. somehow I figured that I need to create an account.
5. There is no option to create a new account...
6. Try pressing log in and see if it sends me somewhere. Now there is a
small button "Sign up". Finally, let's go.
6. create an account: no SSO: I need write my name, create a new password
on my password manager and wait for an email.
6. wait for verification email and validate
7. press create issue
* type
* Summary (no idea I need to put the component on the title)
* Priority (no idea)
* Due date (no idea)
* component (no idea, let me search some keywords and see if something
matches: perfect, Rust)
* affected version (put latest)
* Add description. Can't use markdown, so some struggle here as
copy-pasting code usually does not work. Need to learn how to use this.
* More 5 fields or so, that I have no idea if it is expected of me to
fill or not.
9. press create
10. Pop up shows up: great, now I have the issue... wait, I forgot, why I
was creating the issue again? Pop up disappears.
11. Ah, right, the issue number. Dam, how do I find it now? The pop up is
gone.
12. Spend an arbitrary amount of time finding the issue.... finally, I
found it.
13. Copy it over to the github, edit the title on github.
14. Oh, I just received two emails from JIRA: someone already commented on
it?!?!
15. Open email, and after some digging about it I conclude that:
* the first email is telling me that the title of the JIRA has been
updated
* the second email is telling me that there is now a PR associated with
the issue. Well, that is a bummer...
16. That bot comment has not disappeared from github. Am I done?
17. (some time later): oh, another email from JIRA: after 1m reading the
diff: ah, someone added some [DataFusion] to the title...
Again, I am adding some clues of what I perceive to be a state of mind of
the person going through this flow, just to point out that IMO we are
talking about no small barrier here. I am also assuming an infinite
willpower.
I do not find JIRA appealing, but I do not find it bad either. I do think
that the setup we have puts too much load on everyone and in my previous
email I tried to express that, for what is worth, that has caused me to
significantly reduce my contributions. I also tried formulating what I see
as the root cause for the current status quo (availability of information
from the project); I hope this one helps to clarify what I meant with "too
much".
In my experience, discussion on JIRA is about the issue itself (for
> example diagnosing a bug or discussing a feature), then discussion on
> the PR is about the implementation. JIRA discussions are generally
> readable by users (and indeed, users often participate) while PR
> discussions are really for developers of the project.
>
In my experience (from Rust alone), little discussion happens on JIRA.
Either on the PRs, google docs, or mailing list. Only one of them supports
markdown, though, which I consider a basic requirement for any product for
developers.
FWIW, I've set up a mail filter that sends all "work logged" automated
> mail to the trashbin. I agree it's unfortunate that developers have to
> do that. I also have other qualms with the Apache JIRA configuration,
> such as the fact that "labels" (keywords) are shared between all
> projects, so there is essentially a million of them with no effort at
> taxonomy.
>
I also struggle with both. I tried at some point adding "beginner friendly"
labels to issues that were so, but there are 5 variants of that label; if I
do not know which one to pick, how can I expect a *beginner* to know which
one to pick?
Best,
Jorge
On Tue, Mar 2, 2021 at 10:26 AM Antoine Pitrou <anto...@python.org> wrote:
>
> Hi Jorge,
>
> On Tue, 2 Mar 2021 08:55:03 +0100
> Jorge Cardoso Leitão <jorgecarlei...@gmail.com> wrote:
> > Hi,
> >
> > FWIW, the amount of bureaucracy that goes into JIRA is a major
> contributing
> > factor for the reduction of my time commitment to this project by 80%+.
>
> Can you expand a bit on this? In particular, which aspects of using
> JIRA feel bureaucratic? Is it the requirement to create a new issue
> for each PR? Or is it other concerns (such as the UI for entering or
> searching issues)?
>
> I can't say I like JIRA myself, but at least it provides the
> classification and navigation features that I would expect from an
> issue tracker. The Github issue tracker AFAIK is rudimentary and not
> really practical when a project has accumulated many issues (but they
> may have changed this recently).
>
> > The major challenge is that most discussions happen where PRs are created
> > and seen, which is on github, but JIRA and mailing list is used for other
> > types of decisions. In this model, how do we preserve curated information
> > about the decision process while at the same time leverage both JIRA and
> > github's capabilities?
>
> In my experience, discussion on JIRA is about the issue itself (for
> example diagnosing a bug or discussing a feature), then discussion on
> the PR is about the implementation. JIRA discussions are generally
> readable by users (and indeed, users often participate) while PR
> discussions are really for developers of the project.
>
> > OTOH, asking contributors to create a jira account
> > and committers to add the person as contributor, as well as the email
> spam
> > and the merge process is a large barrier.
>
> FWIW, I've set up a mail filter that sends all "work logged" automated
> mail to the trashbin. I agree it's unfortunate that developers have to
> do that. I also have other qualms with the Apache JIRA configuration,
> such as the fact that "labels" (keywords) are shared between all
> projects, so there is essentially a million of them with no effort at
> taxonomy.
>
> > IMO the foundation could be clearer wrt to what does it mean with
> > information being preserved and available (e.g. on apache servers?) and
> if
> > yes, follow it through by hosting all their projects on their own github
> /
> > gitlab / whatever, where issues and PRs are on the same platform, and
> offer
> > SSO for contributors as a way to prove identity across the system. But
> that
> > is also a complex operation with a lot of unknowns...
>
> From what I see of the ASF's velocity, I wouldn't expect such a large
> breakthrough in the short future.
>
> (this is not trying to badmouth the ASF, just a pragmatic evaluation)
>
> Regards
>
> Antoine.
>
>
>
