Whoops, didn’t mean to send that out to the list. Apologies. Somehow, an
earlier draft of my email got sent out.
Nick
2017년 10월 5일 (목) 오전 9:20, Nicholas Chammas 님이
작성:
> The first sign that that conversation was going to go downhill was when
> the user [demanded](
> https://issues.apache.org/ji
That makes more sense. If this is something that committers can do to stop
a single issue from being reopened, I'm more okay with that. But we need to
make sure that we don't accidentally use it when closing issues or over-use
it. I guess I'm +0 on it.
On Thu, Oct 5, 2017 at 9:04 AM, Sean Owen wr
I missed Steve's comments :(
That looks like a really healthy process, but also time consuming.
I guess that's what it takes to make a community?
Gary
Yeah to be clear I'm not suggesting that -- issues are just "Resolved" in
general which anyone can continue reopening. That's exactly because new
facts can come to light, a different opinion can arrive later, etc.
I'm trying to have some control over someone repeatedly reopening issues
every 15 mi
As a casual reader of the dev mailing group / Spark JIRA
This looks reasonable to me. I read the JIRA in question and although I
didn't spend enough time to really dig into the issues presented I think
it's reasonable to close in this situation.
If the person with the grievance feels strongly it
While I have also felt this frustration and understand the motivation, I
don't think it's a good idea to disallow people from reopening issues.
Like Steve said, this is something that is better dealt with socially. If
we did implement this, we're shutting out the polite people when *we* make
mista
It's, Closed -> Reopened (not, Resolved -> Reopened) and I think we mostly
leave JIRAs as Resolved.
I support this idea. I think don't think this is unfriendly as it sounds in
practice. This case should be quite occasional I guess.
2017-10-05 20:02 GMT+09:00 Sean Owen :
> Solving it socially is
It's a losing battle which you need to deal with socially rather than through
the tooling...if the user is unhappy then at best they don't use the code,
don't contribute in future, at worse: they keep filing the same JIRA. I'll add
a comment
In hadoop we've ended up creating a wiki page added a
Solving it socially is of course ideal. We do already likewise point
everyone to http://spark.apache.org/contributing.html . I think this is
about what to do in extreme cases. It's a minor point of workflow, but,
seems like there's no particular need to let anyone reopen any issue.
Speaking to the
M
> *To:* Dongjoon Hyun
> *Cc:* dev
> *Subject:* Re: Disabling Closed -> Reopened transition for non-committers
>
> Although I assume we could get an account suspended if it started opening
> spam issues, yes we default to letting anyone open issues, and potentially
> abusi
To: Dongjoon Hyun
Cc: dev
Subject: Re: Disabling Closed -> Reopened transition for non-committers
Although I assume we could get an account suspended if it started opening spam
issues, yes we default to letting anyone open issues, and potentially abusing
it. That much is the right default an
Although I assume we could get an account suspended if it started opening
spam issues, yes we default to letting anyone open issues, and potentially
abusing it. That much is the right default and I don't see any policy tweak
that stops that.
I see several INFRA tickets asking to *allow* the Closed
It can stop reopening, but new JIRA issues with duplicate content will be
created intentionally instead.
Is that policy (privileged reopening) used in other Apache communities for
that purpose?
On Wed, Oct 4, 2017 at 7:06 PM, Sean Owen wrote:
> We have this problem occasionally, where a disgru
13 matches
Mail list logo
