airflow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From airflowuser <airflowu...@protonmail.com.INVALID>
Subject Re: It's very hard to become a committer on the project
Date Thu, 20 Sep 2018 08:59:08 GMT
If the Jira could be converted into read only then there is no problem.
Having 1000+ tickets on Jira isn't really an issue. It's not like committers actually pass
the tickets and choose what to do from it. Tickets of 2017, 2016 are most likely to never
be fixed or even already have been fixed but no one will check it.
Note that many tickets are on 1.7 and 1.8

Again, If decided to stay with Jira.. I highly recommend that someone from the project will
maintain it. Don't allow to regular users to tag and set priorities for the tickets.. someone
from the project should do it.

Remember my basic question: I want to contribute - how on earth I can find a ticket that is
suitable for first time committer? Can you show me?

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, September 18, 2018 11:57 AM, Sid Anand <sanand@apache.org> wrote:

> Hi Folks!
> For some history, Airlfow started on GH issues. We also had a very popular Google group.
When we moved to Apache, we were told that Jira was the way we needed to go for issue tracking
because it resided on Apache infrastructure. When we moved over, we had to drop 100+ GH issues
on the floor -- there was no way to transfer them to Jira and maintain the original submitter/owner
info since there was no mapping of users between the 2 systems.
>
> Here's a pie chart of our existing issues by status:
> [https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=project-12320023&statistictype=statuses&selectedProjectId=12320023&reportKey=com.atlassian.jira.jira-core-reports-plugin%3Apie-report&atl_token=A5KQ-2QAV-T4JA-FDED|a85ff737799378265f90bab4f1456b5e2811a507|lin&Next=Next](https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=project-12320023&statistictype=statuses&selectedProjectId=12320023&reportKey=com.atlassian.jira.jira-core-reports-plugin%3Apie-report&atl_token=A5KQ-2QAV-T4JA-FDED%7Ca85ff737799378265f90bab4f1456b5e2811a507%7Clin&Next=Next)
>
> I'm attaching a screen shot as well.
>
> I think we all agree that there is better integration between GH PRs and GH Issues than
between GH PRs and Jira issues.
>
> There are some practical matters to consider:
>
> - For the 1100-1200 unclosed/unresolved issues, how will we transfer them to GH or will
we drop those on the floor? How would we map submitters between the 2 systems, and how would
we transfer the content/comments,etc...
> - For the existing closed PRs (>3k), whose PRs reference JIRA, we'd need to keep JIRA
around in read-only mode so we could reference the bug/feature details, but somehow disallow
new JIRA creations, lest some people continue to use it to create new issues
> - I'm assuming the GH issue naming would not conflict with that of JIRA naming in commit
message subjects and PRs. In other words, incubator-airlow-1 vs AIRFLOW-1 or airflow-1 vs
AIRFLOW-1 or possibly conflict at AIRFLOW-1? Once we graduate, I'm pretty sure the incubator
name will be dropped, so there may be a naming conflict.
>
> In the end, these are 2 different tools. The issues you raise are mainly around governance.
>
> If you folks would like to propose a new means to manage the JIRAs, can you outline a
solution on Wiki and drop a link into an email on this list? We can then raise a vote.
>
> IMHO, our community would scale the best if more people picked up responsibilities such
as these. Grooming/Organizing JIRAs doesn't need to be a responsibility owned by the maintainers.
Anyone can take the lead on discussions, etc...
>
> -s
>
> On Mon, Sep 17, 2018 at 2:09 AM Sumit Maheshwari <sumeet.manit@gmail.com> wrote:
>
>> Strong +1 for moving to GitHub from Jira.
>>
>> On Mon, Sep 17, 2018 at 12:35 PM George Leslie-Waksman <waksman@gmail.com>
>> wrote:
>>
>>> Are there Apache rules preventing us from switching to GitHub Issues?
>>>
>>> That seems like it might better fit much of Airflow's user base.
>>>
>>>
>>> On Sun, Sep 16, 2018, 9:21 AM Jeff Payne <jpayne@bombora.com> wrote:
>>>
>>> > I agree that Jira could be better utilized. I read the original
>>> > conversation on the mailing list about how Jira should be used (or if it
>>> > should be used at all) and I'm still unclear about why it was picked over
>>> > just using github issues. It refers to a dashboard, which I've yet to
>>> > investigate, but Jira is much more than just dashboards.
>>> >
>>> > If this project is going to use Jira, then:
>>> >
>>> > 1) It would be great to see moderation and labeling of the Jira issues by
>>> > the main contributors to make it easier for people to break into
>>> > contributing.
>>> > 2) It would also be nice if the initial conversation of whether or not an
>>> > issue warrants development at all happened on the Jira issue, or at least
>>> > some acknowledgement by the main contributors.
>>> > 3) Larger enhancements and efforts or vague suggestions still get
>>> > discussed on the dev mailing list before a Jira is even opened, but after
>>> > that, the discussion moves to the Jira, with a link back to the mailing
>>> > list email for reference.
>>> > 4) The discussion on the PR is only concerned with HOW the change/fix is
>>> > implemented.
>>> >
>>> > Get Outlook for Android<https://aka.ms/ghei36>
>>> >
>>> > ________________________________
>>> > From: James Meickle <jmeickle@quantopian.com.INVALID>
>>> > Sent: Sunday, September 16, 2018 7:46:58 AM
>>> > To: dev@airflow.apache.org
>>> > Subject: Re: It's very hard to become a committer on the project
>>> >
>>> > Definitely agree with this. I'm not always opposed to JIRA for projects,
>>> > but the way it's being used for this project makes it very hard to break
>>> > into contributing. The split between GH and JIRA is also painful since
>>> > there's no automatic integration of them.
>>> >
>>> > On Sun, Sep 16, 2018 at 9:29 AM airflowuser
>>> > <airflowuser@protonmail.com.invalid> wrote:
>>> >
>>> > > Hello all,
>>> > >
>>> > > I'm struggling finding tickets to address and while discussing it on
>>> chat
>>> > > others reported they had the same problem when they began working on
>>> the
>>> > > project.
>>> > >
>>> > > The problem is due to:
>>> > > 1. It's very hard to locate tickets on Jira. The categories are a mess,
>>> > > versions are not enforced. each use can tag,label and set priority
at
>>> his
>>> > > will. No one monitor or overwrite it
>>> > > 2. It's impossible for a new committer to  find issues which can be
>>> > > easy-fix and a "good first issue".
>>> > >
>>> > > My suggestions:
>>> > > 1. Looking at the ticket system there are usually less than 10 new
>>> > tickets
>>> > > a day. It won't take too much time for someone with knowledge on the
>>> > > project to properly tag  the ticket.
>>> > >
>>> > > 2. I think that most of you don't even check the Jira. Most of you
>>> submit
>>> > > PRs and 5 seconds before opening a ticket (just because you must).
>>> There
>>> > is
>>> > > no doubt that the Jira is a "side" system which doesn't really perform
>>> > it's
>>> > > job.
>>> > >
>>> > > Take a look at this:
>>> > > https://issues.apache.org/jira/projects/AIRFLOW/issues/AIRFLOW-2999
>>> > > a member of the community asks for committers for input but no one
>>> > > replies. I doubt this is because no one has input.. I am sure that
if a
>>> > PR
>>> > > was submitted you had comments. It's simply because you don't see it.
>>> > This
>>> > > is why I think the current Jira does't function properly. I think that
>>> > > Github can perform a better role. All of you as committers are already
>>> > > there and it's always better to work with one system rather with two.
>>> The
>>> > > colors and labels of the GitHub as very easy to notice.
>>> > >
>>> > > Either way, what ever you decide something needs to be change. Either
>>> > Jira
>>> > > will be more informative or move to GitHub.
>>> > >
>>> > > Thank you all for your good work :)
>>> >
>>>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message