JIRAs with user facing changes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

JIRAs with user facing changes

Noble Paul നോബിള്‍  नोब्ळ्
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: JIRAs with user facing changes

Andrzej Białecki-2
+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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: JIRAs with user facing changes

Noble Paul നോബിള്‍  नोब्ळ्
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


--
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: JIRAs with user facing changes

David Smiley
+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


On Sun, Oct 18, 2020 at 1:39 AM Noble Paul <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


--
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: JIRAs with user facing changes

Houston Putman
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 <[hidden email]> 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


On Sun, Oct 18, 2020 at 1:39 AM Noble Paul <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


--
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]