Re: Soften Jira's note when opening new issues?

[Walter Underwood]

I have a search story from Netflix about how much the first words matter.

We had two movies named “The Other Boleyn Girl”. One was an older BBC 
miniseries and the other was a recent Hollywood film. The BBC result was #1, 
which seemed wrong, but it was in more rental queues, so people really were 
adding it. The images were just women in big taffeta dresses, and the 
description for the Hollywood film started with something like “From acclaimed 
director …”, so it was hard to tell which was which.

I asked the movie metadata team to reword the description of the Hollywood film 
so that the first two words were “Nicole Kidman”. They pushed the change, and 
one hour later, the Hollywood film was the first result.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

> On Sep 24, 2021, at 11:59 AM, David Smiley  wrote:
> 
> Agreed Walter.  At least it's better than before.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
> 
> 
> On Fri, Sep 24, 2021 at 11:09 AM Walter Underwood  > wrote:
> it seems odd too start with a statement that there is a mailing list without 
> any idea why the person cares. That is why my suggestions started with the 
> person’s need, not with the bare fact of the mailing list. 
> 
> People are likely to skip over that whole paragraph after they scan “This 
> project has a use mailing list…”. The first few words are by far the most 
> important. Again, I strongly suggest starting with "If you want help or have 
> a feature idea…”
> 
> wunder
> Walter Underwood
> wun...@wunderwood.org 
> http://observer.wunderwood.org/   (my blog)
> 
>> On Sep 24, 2021, at 12:57 AM, Adrien Grand > > wrote:
>> 
>> Infra helped me change the message 
>>  yesterday, thanks for 
>> the discussion on this thread.
>> 
>> +1 on your PR to the project's README.
>> 
>> The problem I saw with Jira recently - and I acknowledge that there might be 
>> a bias - is that users had read our HowToContribute guide already, which 
>> suggests opening a Jira. But then Jira told these contributors to go to the 
>> mailing-list first before we updated the message. I like the idea of linking 
>> HowToContribute from the perspective that it would be welcoming and 
>> encourage contributions, but it would increase the amount of text that you 
>> have to read when using Jira yet the anecdotal evidence I have is that these 
>> contributors were already familiar with the HowToContribute since it is the 
>> thing that led them to Jira in the first place. No strong feelings, I could 
>> be convinced otherwise but wanted to give this perspective.
>> 
>> On Thu, Sep 23, 2021 at 7:41 PM Greg Miller > > wrote:
>> Hi Adrien- that's totally fair. There are probably better places for
>> the additional content I'm proposing. A couple things along these
>> lines:
>> 
>> 1. Do you think it would be worth linking this guide from the JIRA
>> message (maybe after updating it)?
>> https://cwiki.apache.org/confluence/display/lucene/HowToContribute 
>> . It
>> could be a nice hook for new users to learn more (and it's what we
>> link from our README). Maybe it would make the message too long
>> though?
>> 2. I just put up a very brief PR to add my proposed "friendly message"
>> to the README before linking off to the above-mentioned guide:
>> https://github.com/apache/lucene/pull/318 
>> .
>> 
>> Back to your original proposal though, I'll add my +1 as I think it's
>> a big improvement from the current messaging. Thanks for bringing this
>> up!
>> 
>> Cheers,
>> -Greg
>> 
>> On Wed, Sep 22, 2021 at 9:23 AM Walter Underwood > > wrote:
>> >
>> > Hmm. How is this? It is a single longer sentence, but essentially a string 
>> > of simple ones.
>> >
>> > If you want help or have a feature idea, please ask on the mailing list or 
>> > IRC channel before submitting a Jira issue.
>> >
>> > wunder
>> > Walter Underwood
>> > wun...@wunderwood.org 
>> > http://observer.wunderwood.org/   (my 
>> > blog)
>> >
>> > On Sep 22, 2021, at 9:18 AM, Adrien Grand > > > wrote:
>> >
>> > Greg, I understand and agree with the intent, but I also would like to 
>> > keep this as short as possible since the screen to create a new issue in 
>> > JIRA is already quite intimidating with all its text boxes, and the 
>> > current version is already taking two lines even though it's short. Maybe 
>> > this is the sort of thing that we could try to better emphasize in our 
>> > project's README?
>> >
>> > On Wed, Sep 22, 2021 at 6:07

Re: Soften Jira's note when opening new issues?

[David Smiley]

Agreed Walter.  At least it's better than before.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Fri, Sep 24, 2021 at 11:09 AM Walter Underwood 
wrote:

> it seems odd too start with a statement that there is a mailing list
> without any idea why the person cares. That is why my suggestions started
> with the person’s need, not with the bare fact of the mailing list.
>
> People are likely to skip over that whole paragraph after they scan “This
> project has a use mailing list…”. The first few words are by far the most
> important. Again, I strongly suggest starting with "If you want help or
> have a feature idea…”
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
> On Sep 24, 2021, at 12:57 AM, Adrien Grand  wrote:
>
> Infra helped me change the message
>  yesterday, thanks for
> the discussion on this thread.
>
> +1 on your PR to the project's README.
>
> The problem I saw with Jira recently - and I acknowledge that there might
> be a bias - is that users had read our HowToContribute guide already, which
> suggests opening a Jira. But then Jira told these contributors to go to the
> mailing-list first before we updated the message. I like the idea of
> linking HowToContribute from the perspective that it would be welcoming and
> encourage contributions, but it would increase the amount of text that you
> have to read when using Jira yet the anecdotal evidence I have is that
> these contributors were already familiar with the HowToContribute since it
> is the thing that led them to Jira in the first place. No strong feelings,
> I could be convinced otherwise but wanted to give this perspective.
>
> On Thu, Sep 23, 2021 at 7:41 PM Greg Miller  wrote:
>
>> Hi Adrien- that's totally fair. There are probably better places for
>> the additional content I'm proposing. A couple things along these
>> lines:
>>
>> 1. Do you think it would be worth linking this guide from the JIRA
>> message (maybe after updating it)?
>> https://cwiki.apache.org/confluence/display/lucene/HowToContribute. It
>> could be a nice hook for new users to learn more (and it's what we
>> link from our README). Maybe it would make the message too long
>> though?
>> 2. I just put up a very brief PR to add my proposed "friendly message"
>> to the README before linking off to the above-mentioned guide:
>> https://github.com/apache/lucene/pull/318.
>>
>> Back to your original proposal though, I'll add my +1 as I think it's
>> a big improvement from the current messaging. Thanks for bringing this
>> up!
>>
>> Cheers,
>> -Greg
>>
>> On Wed, Sep 22, 2021 at 9:23 AM Walter Underwood 
>> wrote:
>> >
>> > Hmm. How is this? It is a single longer sentence, but essentially a
>> string of simple ones.
>> >
>> > If you want help or have a feature idea, please ask on the mailing list
>> or IRC channel before submitting a Jira issue.
>> >
>> > wunder
>> > Walter Underwood
>> > wun...@wunderwood.org
>> > http://observer.wunderwood.org/  (my blog)
>> >
>> > On Sep 22, 2021, at 9:18 AM, Adrien Grand  wrote:
>> >
>> > Greg, I understand and agree with the intent, but I also would like to
>> keep this as short as possible since the screen to create a new issue in
>> JIRA is already quite intimidating with all its text boxes, and the current
>> version is already taking two lines even though it's short. Maybe this is
>> the sort of thing that we could try to better emphasize in our project's
>> README?
>> >
>> > On Wed, Sep 22, 2021 at 6:07 PM Walter Underwood 
>> wrote:
>> >>
>> >> Two excellent points. So it could be:
>> >>
>> >> Are you looking for support for Lucene? Have you seen unexpected
>> behavior? Have an idea for a new feature or improvement? Please ask for
>> help on the Lucene user mailing list or the IRC channel. If it is a new
>> problem or idea, then you can submit a Jira issue.
>> >>
>> >> wunder
>> >> Walter Underwood
>> >> wun...@wunderwood.org
>> >> http://observer.wunderwood.org/  (my blog)
>> >>
>> >> On Sep 22, 2021, at 6:38 AM, Greg Miller  wrote:
>> >>
>> >> Love this idea!
>> >>
>> >> I wonder if there's a way to make the messaging clear that ideas for
>> >> new features/improvements are also always welcome? When I read the
>> >> current language, I interpret it as bug reporting. Maybe adding a
>> >> leading sentence would help?
>> >>
>> >> ```
>> >> Bug reports, improvements and new feature ideas are always welcome!
>> >> Please note, this project has a user mailing list and an IRC channel
>> >> for support. If you are looking for support, or if you are not sure
>> >> whether the behavior that you are observing is expected or not, please
>> >> discuss it there first.
>> >> ```
>> >>
>> >> Cheers,
>> >> -Greg
>> >>
>> >> On Wed, Sep 22, 2021 at 5:35 AM Adrien Grand 
>> wrote:
>> >>
>> >>
>> >> Hi Walter,
>> >>
>> >> Though it doesn't invalidate your comment, I was considering changing
>> t

Re: Accessibility of SegmentInfo::setDiagnostics

[Adrien Grand]

I'd +1 a change that makes setDiagnostics public. Longer term I wonder if
we should have a more locked down API that _only_ allows setting
diagnostics. There are lots of things in SegmentCommitInfo that merges
should never override like the segment ID, and I can't think of anything
else than diagnostics that a merge policy should ever need to set.

On Fri, Sep 24, 2021 at 10:57 AM Chris Hegarty
 wrote:

> In an effort to prepare Elasticsearch for modularization, we are
> investigating and eliminating split packages. The situation has improved
> through recent refactoring in Lucene 9.0 [1], but a number of split
> packages still remain. This message identifies one such so that it can
> be discussed in isolation, with a view to a potential solution either in
> Lucene or possibly within Elasticsearch itself.
>
> Elasticsearch has a custom merge policy, ShuffleForcedMergePolicy, that
> interleaves eldest and newest segments. SFMP has but a single
> package-private dependency on lucene, namely `SegmentInfo::setDiagnostics`.
> The `setDiagnostics` method is used by SFMP to add a single additional
> ES-specific diagnostic key.
>
> It is possible to recreate the whole SegmentCommitInfo (and the SI
> within, along with the additional ES-specific diagnostic key), by using
> just the accessible parts of the lucene API. This has been prototyped[2],
> but shows that something is not quite right [3]. Resolving this issue is
> likely better done in lucene.
>
> The comment in `MergePolicy::setMergeInfo` - "Sets the SegmentCommitInfo
> of the merged segment. Allows sub-classes to e.g. set diagnostics
> properties"[4] - is telling. To better support the use-cases referred to
> in this comment and to allow for other-package subclasses (which seems
> completely reasonable given other parts of the API), it would be better
> for lucene's SI::setDiagnostics method to be public (rather than
> package-private). Such a change is a general improvement in the lucene
> API, which can be leveraged by any custom merge policy.
>
> -Chris.
>
> [1] https://issues.apache.org/jira/browse/LUCENE-9319
> [2] https://github.com/elastic/elasticsearch/pull/78253
> [3]
> https://github.com/elastic/elasticsearch/pull/78253#issuecomment-925861893
> [4]
> https://github.com/apache/lucene/blob/d5d6dc079395c47cd6d12dcce3bcfdd2c7d9dc63/lucene/core/src/java/org/apache/lucene/index/MergePolicy.java#L271
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Adrien

Re: Soften Jira's note when opening new issues?

[Walter Underwood]

it seems odd too start with a statement that there is a mailing list without 
any idea why the person cares. That is why my suggestions started with the 
person’s need, not with the bare fact of the mailing list. 

People are likely to skip over that whole paragraph after they scan “This 
project has a use mailing list…”. The first few words are by far the most 
important. Again, I strongly suggest starting with "If you want help or have a 
feature idea…”

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

> On Sep 24, 2021, at 12:57 AM, Adrien Grand  wrote:
> 
> Infra helped me change the message 
>  yesterday, thanks for the 
> discussion on this thread.
> 
> +1 on your PR to the project's README.
> 
> The problem I saw with Jira recently - and I acknowledge that there might be 
> a bias - is that users had read our HowToContribute guide already, which 
> suggests opening a Jira. But then Jira told these contributors to go to the 
> mailing-list first before we updated the message. I like the idea of linking 
> HowToContribute from the perspective that it would be welcoming and encourage 
> contributions, but it would increase the amount of text that you have to read 
> when using Jira yet the anecdotal evidence I have is that these contributors 
> were already familiar with the HowToContribute since it is the thing that led 
> them to Jira in the first place. No strong feelings, I could be convinced 
> otherwise but wanted to give this perspective.
> 
> On Thu, Sep 23, 2021 at 7:41 PM Greg Miller  > wrote:
> Hi Adrien- that's totally fair. There are probably better places for
> the additional content I'm proposing. A couple things along these
> lines:
> 
> 1. Do you think it would be worth linking this guide from the JIRA
> message (maybe after updating it)?
> https://cwiki.apache.org/confluence/display/lucene/HowToContribute 
> . It
> could be a nice hook for new users to learn more (and it's what we
> link from our README). Maybe it would make the message too long
> though?
> 2. I just put up a very brief PR to add my proposed "friendly message"
> to the README before linking off to the above-mentioned guide:
> https://github.com/apache/lucene/pull/318 
> .
> 
> Back to your original proposal though, I'll add my +1 as I think it's
> a big improvement from the current messaging. Thanks for bringing this
> up!
> 
> Cheers,
> -Greg
> 
> On Wed, Sep 22, 2021 at 9:23 AM Walter Underwood  > wrote:
> >
> > Hmm. How is this? It is a single longer sentence, but essentially a string 
> > of simple ones.
> >
> > If you want help or have a feature idea, please ask on the mailing list or 
> > IRC channel before submitting a Jira issue.
> >
> > wunder
> > Walter Underwood
> > wun...@wunderwood.org 
> > http://observer.wunderwood.org/   (my blog)
> >
> > On Sep 22, 2021, at 9:18 AM, Adrien Grand  > > wrote:
> >
> > Greg, I understand and agree with the intent, but I also would like to keep 
> > this as short as possible since the screen to create a new issue in JIRA is 
> > already quite intimidating with all its text boxes, and the current version 
> > is already taking two lines even though it's short. Maybe this is the sort 
> > of thing that we could try to better emphasize in our project's README?
> >
> > On Wed, Sep 22, 2021 at 6:07 PM Walter Underwood  > > wrote:
> >>
> >> Two excellent points. So it could be:
> >>
> >> Are you looking for support for Lucene? Have you seen unexpected behavior? 
> >> Have an idea for a new feature or improvement? Please ask for help on the 
> >> Lucene user mailing list or the IRC channel. If it is a new problem or 
> >> idea, then you can submit a Jira issue.
> >>
> >> wunder
> >> Walter Underwood
> >> wun...@wunderwood.org 
> >> http://observer.wunderwood.org/   (my 
> >> blog)
> >>
> >> On Sep 22, 2021, at 6:38 AM, Greg Miller  >> > wrote:
> >>
> >> Love this idea!
> >>
> >> I wonder if there's a way to make the messaging clear that ideas for
> >> new features/improvements are also always welcome? When I read the
> >> current language, I interpret it as bug reporting. Maybe adding a
> >> leading sentence would help?
> >>
> >> ```
> >> Bug reports, improvements and new feature ideas are always welcome!
> >> Please note, this project has a user mailing list and an IRC channel
> >> for support. If you are looking for support, or if you are not sure
> >> whether the behavior that you are observing is expected or not, please
> >> discuss it there first.
> >> ```
> >>
> >> Cheers,
> >> -Greg
> >>
> >> On Wed, Sep 22, 2021

Re: [jira] [Commented] (LUCENE-10062) Explore using SORTED_NUMERIC doc values to encode taxonomy ordinals for faceting

[Michael Sokolov]

Hard to read on the phone, but is that a 482% speed up I saw??!

On Thu, Sep 23, 2021, 1:28 PM Greg Miller (Jira)  wrote:

>
> [
> https://issues.apache.org/jira/browse/LUCENE-10062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17419349#comment-17419349
> ]
>
> Greg Miller commented on LUCENE-10062:
> --
>
> I re-ran {{luceneutil}} benchmarks {{wikimedium10m}} since [~mikemccand]
> added new faceting tasks (thanks Mike!). Looks like there's a nice
> improvement on these new faceting tasks as well with this change (and no
> regressions anywhere else that I see).
>
> I was waiting to iterate on my PR until I was able to run these new
> benchmarking tasks, but it seems like there's enough benefit to this change
> to pick it back up.
>
>
> {noformat}
> TaskQPS baseline  StdDevQPS candidate
> StdDevPct diff p-value
>HighTermDayOfYearSort   70.02 (13.7%)   68.45
> (9.7%)   -2.2% ( -22% -   24%) 0.551
>  MedTerm 1300.90  (5.5%) 1275.97
> (6.7%)   -1.9% ( -13% -   10%) 0.324
> HighTerm 1953.46  (5.8%) 1925.79
> (7.9%)   -1.4% ( -14% -   13%) 0.518
> HighTermTitleBDVSort  122.35 (15.6%)  120.86
>  (14.9%)   -1.2% ( -27% -   34%) 0.801
>   TermDTSort  133.47  (8.7%)  131.86
> (7.4%)   -1.2% ( -15% -   16%) 0.637
>  LowTerm 1636.13  (5.5%) 1622.34
> (7.4%)   -0.8% ( -12% -   12%) 0.682
>  Prefix3   25.69  (6.0%)   25.48
> (6.3%)   -0.8% ( -12% -   12%) 0.676
>  LowSpanNear  118.02  (2.1%)  117.31
> (1.8%)   -0.6% (  -4% -3%) 0.326
>HighTermMonthSort  140.17  (9.8%)  139.47
> (9.9%)   -0.5% ( -18% -   21%) 0.872
>  AndHighHigh   49.17  (3.1%)   48.92
> (2.7%)   -0.5% (  -6% -5%) 0.584
> HighSpanNear   25.54  (2.7%)   25.41
> (2.2%)   -0.5% (  -5% -4%) 0.529
>   AndHighLow  556.68  (5.8%)  554.80
> (5.4%)   -0.3% ( -10% -   11%) 0.848
>BrowseDayOfYearSSDVFacets   16.53  (2.5%)   16.47
> (2.4%)   -0.3% (  -5% -4%) 0.674
>   IntNRQ   87.76  (2.0%)   87.49
> (2.1%)   -0.3% (  -4% -3%) 0.634
>  MedSpanNear   31.11  (2.2%)   31.04
> (1.6%)   -0.2% (  -3% -3%) 0.714
> OrNotHighLow  765.10  (4.5%)  763.60
> (5.4%)   -0.2% (  -9% -   10%) 0.901
>MedPhrase  160.05  (3.1%)  159.83
> (2.9%)   -0.1% (  -5% -6%) 0.885
> HighSloppyPhrase   27.67  (3.1%)   27.64
> (3.0%)   -0.1% (  -6% -6%) 0.915
>LowPhrase   61.12  (3.2%)   61.05
> (3.2%)   -0.1% (  -6% -6%) 0.921
>OrHighMed   71.85  (2.9%)   71.82
> (2.1%)   -0.0% (  -4% -5%) 0.963
>   HighPhrase   29.40  (2.3%)   29.39
> (2.8%)   -0.0% (  -5% -5%) 0.971
>   Fuzzy2   32.58  (4.3%)   32.57
> (6.1%)   -0.0% (  -9% -   10%) 0.992
>  LowIntervalsOrdered  150.30  (1.9%)  150.28
> (1.9%)   -0.0% (  -3% -3%) 0.986
>   AndHighMed  151.32  (3.9%)  151.31
> (4.1%)   -0.0% (  -7% -8%) 0.993
>   OrHighHigh   23.90  (2.3%)   23.91
> (1.9%)0.0% (  -4% -4%) 0.970
> OrHighNotLow  579.17  (5.1%)  579.35
> (6.4%)0.0% ( -10% -   12%) 0.986
>  MedIntervalsOrdered   86.93  (1.7%)   86.98
> (1.9%)0.1% (  -3% -3%) 0.913
>OrHighNotHigh  536.17  (5.6%)  536.57
> (6.6%)0.1% ( -11% -   12%) 0.969
>OrNotHighHigh  787.07  (6.5%)  787.96
> (8.1%)0.1% ( -13% -   15%) 0.961
> OrNotHighMed  687.97  (4.7%)  688.77
> (6.9%)0.1% ( -10% -   12%) 0.950
>  MedSloppyPhrase   68.62  (2.8%)   68.74
> (2.7%)0.2% (  -5% -5%) 0.838
>  LowSloppyPhrase  130.37  (2.6%)  130.62
> (2.2%)0.2% (  -4% -5%) 0.797
>OrHighLow  440.44  (4.1%)  441.33
> (4.1%)0.2% (  -7% -8%) 0.877
> Wildcard  122.01  (5.2%)  122.35
> (5.3%)0.3% (  -9% -   11%) 0.867
> HighIntervalsOrdered   14.24  (2.2%)   14.34
> (2.1%)0.6% (  -3% -5%) 0.350
>  Respell   52.04  (2.2%)   52.48
> (2.0%)0.8% (  -3% -5%) 0.209
> OrHighNotMed  674.76  (4.8%)  680.97
> (8.0%)0.9

Accessibility of SegmentInfo::setDiagnostics

[Chris Hegarty]

In an effort to prepare Elasticsearch for modularization, we are
investigating and eliminating split packages. The situation has improved
through recent refactoring in Lucene 9.0 [1], but a number of split
packages still remain. This message identifies one such so that it can
be discussed in isolation, with a view to a potential solution either in
Lucene or possibly within Elasticsearch itself.

Elasticsearch has a custom merge policy, ShuffleForcedMergePolicy, that
interleaves eldest and newest segments. SFMP has but a single
package-private dependency on lucene, namely `SegmentInfo::setDiagnostics`.
The `setDiagnostics` method is used by SFMP to add a single additional
ES-specific diagnostic key.

It is possible to recreate the whole SegmentCommitInfo (and the SI
within, along with the additional ES-specific diagnostic key), by using
just the accessible parts of the lucene API. This has been prototyped[2],
but shows that something is not quite right [3]. Resolving this issue is
likely better done in lucene.

The comment in `MergePolicy::setMergeInfo` - "Sets the SegmentCommitInfo
of the merged segment. Allows sub-classes to e.g. set diagnostics
properties"[4] - is telling. To better support the use-cases referred to
in this comment and to allow for other-package subclasses (which seems
completely reasonable given other parts of the API), it would be better
for lucene's SI::setDiagnostics method to be public (rather than
package-private). Such a change is a general improvement in the lucene
API, which can be leveraged by any custom merge policy.

-Chris.

[1] https://issues.apache.org/jira/browse/LUCENE-9319
[2] https://github.com/elastic/elasticsearch/pull/78253
[3] https://github.com/elastic/elasticsearch/pull/78253#issuecomment-925861893
[4] 
https://github.com/apache/lucene/blob/d5d6dc079395c47cd6d12dcce3bcfdd2c7d9dc63/lucene/core/src/java/org/apache/lucene/index/MergePolicy.java#L271
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Release Lucene/Solr 8.10.0 RC1

[Namgyu Kim]

+1 SUCCESS! [1:01:04.224368]

On Thu, Sep 23, 2021 at 12:42 AM Timothy Potter 
wrote:

> Please vote for release candidate 1 for Lucene/Solr 8.10.0
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.0-RC1-rev377e7349979f8e418eacf03f1379b3dfacf7cccb
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.0-RC1-rev377e7349979f8e418eacf03f1379b3dfacf7cccb
>
> The vote will be open for at least 72 hours i.e. until 2021-09-25 16:00
> UTC.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1 (binding) SUCCESS! [0:56:24.357153]
>
>
> Lastly, for those interested in kicking the tires on Solr using
> Docker, I posted an *unofficial* Docker image built locally from the
> RC to: thelabdude/apache-solr-dev:8.10.0-rc1
>
> We just released v0.4.0 of the Apache Solr Operator, so if you want to
> try out this RC on Kubernetes, you can use the following YAML config
> in your SolrCloud CR definition:
>
> solrImage:
>   repository: thelabdude/apache-solr-dev
>   tag: 8.10.0-rc1
>
>
> Cheers,
> Tim
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Soften Jira's note when opening new issues?

[Adrien Grand]

Infra helped me change the message
 yesterday, thanks for
the discussion on this thread.

+1 on your PR to the project's README.

The problem I saw with Jira recently - and I acknowledge that there might
be a bias - is that users had read our HowToContribute guide already, which
suggests opening a Jira. But then Jira told these contributors to go to the
mailing-list first before we updated the message. I like the idea of
linking HowToContribute from the perspective that it would be welcoming and
encourage contributions, but it would increase the amount of text that you
have to read when using Jira yet the anecdotal evidence I have is that
these contributors were already familiar with the HowToContribute since it
is the thing that led them to Jira in the first place. No strong feelings,
I could be convinced otherwise but wanted to give this perspective.

On Thu, Sep 23, 2021 at 7:41 PM Greg Miller  wrote:

> Hi Adrien- that's totally fair. There are probably better places for
> the additional content I'm proposing. A couple things along these
> lines:
>
> 1. Do you think it would be worth linking this guide from the JIRA
> message (maybe after updating it)?
> https://cwiki.apache.org/confluence/display/lucene/HowToContribute. It
> could be a nice hook for new users to learn more (and it's what we
> link from our README). Maybe it would make the message too long
> though?
> 2. I just put up a very brief PR to add my proposed "friendly message"
> to the README before linking off to the above-mentioned guide:
> https://github.com/apache/lucene/pull/318.
>
> Back to your original proposal though, I'll add my +1 as I think it's
> a big improvement from the current messaging. Thanks for bringing this
> up!
>
> Cheers,
> -Greg
>
> On Wed, Sep 22, 2021 at 9:23 AM Walter Underwood 
> wrote:
> >
> > Hmm. How is this? It is a single longer sentence, but essentially a
> string of simple ones.
> >
> > If you want help or have a feature idea, please ask on the mailing list
> or IRC channel before submitting a Jira issue.
> >
> > wunder
> > Walter Underwood
> > wun...@wunderwood.org
> > http://observer.wunderwood.org/  (my blog)
> >
> > On Sep 22, 2021, at 9:18 AM, Adrien Grand  wrote:
> >
> > Greg, I understand and agree with the intent, but I also would like to
> keep this as short as possible since the screen to create a new issue in
> JIRA is already quite intimidating with all its text boxes, and the current
> version is already taking two lines even though it's short. Maybe this is
> the sort of thing that we could try to better emphasize in our project's
> README?
> >
> > On Wed, Sep 22, 2021 at 6:07 PM Walter Underwood 
> wrote:
> >>
> >> Two excellent points. So it could be:
> >>
> >> Are you looking for support for Lucene? Have you seen unexpected
> behavior? Have an idea for a new feature or improvement? Please ask for
> help on the Lucene user mailing list or the IRC channel. If it is a new
> problem or idea, then you can submit a Jira issue.
> >>
> >> wunder
> >> Walter Underwood
> >> wun...@wunderwood.org
> >> http://observer.wunderwood.org/  (my blog)
> >>
> >> On Sep 22, 2021, at 6:38 AM, Greg Miller  wrote:
> >>
> >> Love this idea!
> >>
> >> I wonder if there's a way to make the messaging clear that ideas for
> >> new features/improvements are also always welcome? When I read the
> >> current language, I interpret it as bug reporting. Maybe adding a
> >> leading sentence would help?
> >>
> >> ```
> >> Bug reports, improvements and new feature ideas are always welcome!
> >> Please note, this project has a user mailing list and an IRC channel
> >> for support. If you are looking for support, or if you are not sure
> >> whether the behavior that you are observing is expected or not, please
> >> discuss it there first.
> >> ```
> >>
> >> Cheers,
> >> -Greg
> >>
> >> On Wed, Sep 22, 2021 at 5:35 AM Adrien Grand  wrote:
> >>
> >>
> >> Hi Walter,
> >>
> >> Though it doesn't invalidate your comment, I was considering changing
> the message only for the Lucene JIRA, at least for now.
> >>
> >> On Tue, Sep 21, 2021 at 5:08 PM Walter Underwood 
> wrote:
> >>
> >>
> >> Here is one with shorter, less complex sentences and clear calls to
> action.
> >>
> >> Are you looking for support for Solr? Have you seen unexpected
> behavior? Please ask for help on the Solr user mailing list or the IRC
> channel. If it is a new problem, then you can submit a Jira issue.
> >>
> >> wunder
> >> Walter Underwood
> >> wun...@wunderwood.org
> >> http://observer.wunderwood.org/  (my blog)
> >>
> >> On Sep 21, 2021, at 12:23 AM, Adrien Grand  wrote:
> >>
> >> I think you made a good point, Alexandre. Would something like this
> read better:
> >>
> >> ```
> >> This project has a user mailing list and an IRC channel for support. If
> you are looking for support, or if you are not sure whether the behavior
> that you are observing is expected or not, please discuss it there first.
> >> ```