Re: JIRAs with user facing changes
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 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 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 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 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 >> >>
Re: JIRAs with user facing changes
+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 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 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 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 > >
Re: JIRAs with user facing changes
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 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 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
Re: JIRAs with user facing changes
+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 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
JIRAs with user facing changes
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
