I think this is a really good idea. Formalizing the process would certainly help with consistency throughout Solr. Thanks for bringing it up Noble!
Andrzej, we could possibly use a label for this in JIRA, or add a "component" for it. Adding it as a part of the checklist is a good idea, especially for new contributors. - Houston On Sun, Oct 18, 2020 at 10:25 AM David Smiley <[email protected]> wrote: > +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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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: [email protected] >> > > For additional commands, e-mail: [email protected] >> > > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> >> >> -- >> ----------------------------------------------------- >> Noble Paul >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >>
