+1, Good idea! It's extra work but the peer-review is important and prevents confusion for years to come when a poor choice is made.
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Sun, Oct 18, 2020 at 1:39 AM Noble Paul <noble.p...@gmail.com> wrote: > I don't think we have such an option in JIRA. However, we can add a > similar item to the checklist in github > > On Sat, Oct 17, 2020 at 6:43 PM Andrzej Białecki <a...@getopt.org> wrote: > > > > +1, we should strive to be consistent in the user-facing APIs / configs > / UX. > > > > I’m wondering if there’s any support in Jira for conditional fields, so > that when you create a Jira issue if you tick off an option “Affects the > UX?” it opens a mandatory text field to describe the changes. > > > > > > > On 16 Oct 2020, at 20:19, Noble Paul <noble.p...@gmail.com> wrote: > > > > > > Hi, > > > I'm proposing a process for every ticket which has a user facing > > > change. The changes could be > > > > > > * A new command/end point > > > * A new request parameter > > > * A configuration (solr.xml, clusterprops.json, or any other file in > ZK) > > > * A new file (part of file) in ZK > > > * A new file in file system > > > > > > I may have missed some. > > > > > > Please ensure that the changes are described in the description of the > > > JIRA. This gives a heads up to other committers that a new user facing > > > change is being introduced. > > > > > > Solr's UX is inconsistent & hard and the reason is that we all make > > > user-facing changes without enough review. Of course we add ref guide > > > documentation. But, it is not done until it is too late. The intent to > > > make a change should be made clear well in advance so that we get > > > early feedback. Other committers often see the changes pretty late and > > > at this point it is too late to change because of backward > > > incompatibility. > > > > > > > > > -- > > > ----------------------------------------------------- > > > Noble Paul > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > -- > ----------------------------------------------------- > Noble Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
