I think the user assignment state could be a reasonable proxy to working-on for those that want to do that?
On Tue, Jul 3, 2018 at 12:28 PM Andrzej Białecki < [email protected]> wrote: > > On 3 Jul 2018, at 17:42, Steve Rowe <[email protected]> wrote: > > I forgot to mention on this thread that the “In Progress” status, and the > buttons to control that (“Start Progress”/“Stop Progress”) were removed > from the LUCENE/SOLR workflow because: > > a) Leaving the progress buttons caused the patch review buttons to be > hidden; and > b) I thought the Progress stuff wasn’t really being used much by anybody. > > (The discussion I had with Gavin McDonald about this apparently was only > on Hipchat, so I can’t point people to it since they purposely don’t keep > history. I should have included that in the issue commentary.) > > However, Andrzej Bialecki told me offline that he *did* use the Progress > stuff. > > So: should the Progress elements of the workflow be put back? At a > minimum, even if we don’t put the buttons back because of conflicts with > the patch review buttons, we could re-instate the status and allow it to be > set from the “More” menu or similar. > > > > I did use it … but I can change my workflow as long as there’s a consensus > on what is the expected method for letting the community know that I’m > actively working on something. Steve mentioned to me that these buttons > interfered with the automatic patch review buttons, and I’d rather have > these than the progress buttons. > > I can always add a comment to indicate that “I just started working on > this issue again” and “eh, life interfered and I’m not going to work on > this for a while” … but clicking the buttons required less effort and made > less noise ;) > > > -- > Steve > www.lucidworks.com > > On Jun 28, 2018, at 7:48 PM, Steve Rowe <[email protected]> wrote: > > The new workflow is now enabled for LUCENE and SOLR JIRA projects. > > The new workflow differs in a few respects from my previous summary - see > details inline below: > > On Jun 19, 2018, at 1:53 PM, Steve Rowe <[email protected]> wrote: > > Summary of the workflow changes: > > 1. The “Submit Patch” button will be relabeled “Attach Patch”, and will > bring up the dialog to attach a patch, with a simultaneous comment (rather > than just changing the issue status). This button will remain visible > regardless of issue status, so that it can be used to attach more patches. > > > The new button label was changed to “Attach Files”, since it can be used > to attach non-patch files. > > 2. In the “Attach Patch” dialog, there will be a checkbox labeled “Enable > Automatic Patch Validation”, which will be checked by default. If checked, > the issue’s status will transition to “Patch Available” (which signals > Yetus to perform automatic patch validation); if not checked, the patch > will be attached but no status transition will occur. NOTE: Gavin is still > working on adding this checkbox, so it’s not demo’d on INFRATEST1 issues > yet, but he says it’s doable and that he’ll work on it tomorrow, Australia > time. > > > Since Gavin couldn’t get the “Enable Automatic Patch Validation” checkbox > functionality to work, attaching a file using the “Attach Files” dialog > will never perform any status transitions at all. Instead, users will > enable/disable automatic patch validation via the “Enable Patch Review” and > “Cancel Patch Review” buttons. > > 3. When in “Patch Available” status, a button labeled “Cancel Patch > Review” will be visible; clicking on it will transition the issue status to > “Open”, thus disabling automatic patch review. > > 4. The “Start Progress”/“Stop Progress”/“In Progress” aspects of the > workflow have been removed, because if they remain, JIRA creates a > “Workflow” menu and puts the “Attach Patch” button under it, which kind of > defeats its purpose: an obvious way to submit contributions. I asked Gavin > to remove the “Progress” related aspects of the workflow because I don’t > think they’re being used except on a limited ad-hoc basis, not part of a > conventional workflow. > ----- > > Separate issue: on the thread where Cassandra moved the “Enviroment” field > below “Description” on the Create JIRA dialog[4], David Smiley wrote[5]: > > ok and these Lucene Fields, two checkboxes, New and Patch Available... I > just don't think we really use this but I should raise this separately. > > > I think we should remove these. In a chat on Infra Hipchat, Gavin offered > to do this, but since the Lucene PMC has control of this (as part of > “screen configuration”, which is separate from “workflow” configuration), I > told him we would tackle it ourselves. > > > I’ll make a JIRA for this. > > [1] Enable Yetus for LUCENE/SOLR: > https://issues.apache.org/jira/browse/INFRA-15213 > [2] Modify LUCENE/SOLR Yetus-enabling workflow: > https://issues.apache.org/jira/browse/INFRA-16094 > [3] Demo of proposed LUCENE/SOLR workflow: > https://issues.apache.org/jira/projects/INFRATEST1 > [4] Cassandra fixes Create JIRA dialog: > https://lists.apache.org/thread.html/0efebe2fb08c7584421422d6005401a987a2b54bf604ae317b6e102f@%3Cdev.lucene.apache.org%3E > [5] David Smiley says "Lucene fields” are unused: > https://lists.apache.org/thread.html/a17bd3b5797c12903d3c6bacb348e8b4325c59609765964527412ba4@%3Cdev.lucene.apache.org%3E > > > -- > Steve > www.lucidworks.com > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
