+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
