OK, I made them the same order, with the addition of the Lucene Fields for LUCENE before Environment:
Description Labels Attachments <Lucene Fields> Environment On Tue, Jun 12, 2018 at 10:29 AM Cassandra Targett <[email protected]> wrote: > Yeah, I wasn't sure if folks would want the labels up higher in LUCENE. > It's easy to fix though if the preference is the two forms be mostly the > same (with the exception of the "Lucene Fields"). > > On Tue, Jun 12, 2018 at 10:11 AM David Smiley <[email protected]> > wrote: > >> Much better Cassandra; thanks! >> >> BTW I noticed some small differences in field order on the create screen >> between Lucene and Solr. Solr now has the Environment field at the very >> bottom whereas Lucene has "Lucene Fields" and "Labels" below it. Doesn't >> matter I guess. >> >> On Tue, Jun 12, 2018 at 10:29 AM Cassandra Targett <[email protected]> >> wrote: >> >>> OK, this is done. >>> >>> I was rather aggressive about removing fields for the SOLR project that >>> I know we don't use, but much less so for the LUCENE project. I did ensure >>> that the Environment field is after Description in both projects. >>> >>> I used a mix of looking up the field description in JIRA, querying to >>> see if a field was populated in the JIRA db, and looking up INFRA issues to >>> find out why the field might have been added before removing fields I >>> didn't know already. I have less familiarity with LUCENE issues, so I took >>> a lighter hand, not wanting to ruin individual workflows I'm not fully >>> aware of. >>> >>> As an example, I removed the "Bugzilla ID" field from SOLR screens >>> because it contained no data in the db, but kept it for LUCENE because it >>> does have historical data. I removed "Bugtraq ID" for both, since neither >>> had data there. A "Status Whiteboard" field appeared in the list 3 times >>> but doesn't display and I couldn't figure out at all, so I removed all of >>> them (and that fieldname appears 4x in the JIRA db, but is only used on one >>> single issue system-wide...Oh JIRA & your duplicate fieldnames...). >>> >>> There's probably more to do to tighten it all up, but I thought that was >>> good enough for now and the main goal is accomplished (move Environment >>> down). >>> >>> If I screwed something up, I apologize in advance - let me know and I'll >>> try to put it back. Issues looked the same to me before and afterwards (I >>> checked several, in both projects), but you never know with JIRA when a >>> field is lurking somewhere. >>> >>> Hope it helps - >>> Cassandra >>> >>> On Tue, Jun 12, 2018 at 8:34 AM Cassandra Targett <[email protected]> >>> wrote: >>> >>>> Sure, David, I'll do it this morning. >>>> >>>> When I looked at the fields list for the form in JIRA, there are over >>>> 100 fields set up to display on that form - there's some other bit of >>>> arcane JIRA configuration that defines the fields available for the project >>>> - but I'll remove all but the ones I know we use so they don't just appear >>>> one day and confuse us all again (in case you're curious, some are related >>>> to Bugzilla integration, some are for Hadoop projects, some are duplicates, >>>> etc.). >>>> >>>> On Tue, Jun 12, 2018 at 7:47 AM David Smiley <[email protected]> >>>> wrote: >>>> >>>>> Cassandra, can you please try editing the JIRA config to re-order >>>>> Environment below Description? I suppose Atlassian chose the current >>>>> order >>>>> because it matches the order it's seen when viewing the issue, which makes >>>>> sense but I don't mind sacrificing that -- whatever it takes to diminish >>>>> Environment. >>>>> >>>>> IMO it also is only suitable for a "bug" and not other issue types. >>>>> >>>>> We also don't use "Sprint"; can you remove that? >>>>> >>>>> Scope creep.... 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. >>>>> >>>>> On Fri, Jun 8, 2018 at 2:52 PM Steve Rowe <[email protected]> wrote: >>>>> >>>>>> +1 to try to fix the form ourselves, thanks Cassandra. I think >>>>>> putting Description above Environment will do the trick. (I just created >>>>>> an issue and put the description in the environment field…) >>>>>> >>>>>> -- >>>>>> Steve >>>>>> www.lucidworks.com >>>>>> >>>>>> > On Jun 8, 2018, at 8:44 AM, Cassandra Targett < >>>>>> [email protected]> wrote: >>>>>> > >>>>>> > I've been debating saying something about this too - I think it >>>>>> happened when INFRA added some text to direct users to use the mailing >>>>>> list >>>>>> or IRC if they really have a support question instead of a bug >>>>>> (INFRA-16507). >>>>>> > >>>>>> > The most basic solution is a simple re-ordering of the form, which >>>>>> in JIRA is really easy to do. We could put the environment field near the >>>>>> bottom and if someone is paying attention to the form and wants to fill >>>>>> it >>>>>> in, fine, but the rest of us can get at the most commonly used/needed >>>>>> fields quicker. >>>>>> > >>>>>> > As I was writing that I thought I'd refresh my memory of where >>>>>> screen editing is done in JIRA, and it looks like those of us with >>>>>> committer status have access to edit that form. So we can solve this >>>>>> quickly, and probably we can do it on our own without asking INFRA. >>>>>> > >>>>>> > If we come to consensus on either burying or removing the field, >>>>>> I'd be happy to be the one that makes the change. >>>>>> > >>>>>> > On Fri, Jun 8, 2018 at 7:24 AM David Smiley < >>>>>> [email protected]> wrote: >>>>>> > Many of us have accidentally added a long-form description of our >>>>>> JIRA issues into the Environment field of JIRA instead of the >>>>>> Description. >>>>>> I think we can agree this is pretty annoying. It seems to have been >>>>>> happening more lately with a change to JIRA that for whatever reason has >>>>>> made it more visually tempting to start typing there. I want to arrange >>>>>> for some sort of fix with infra. I'm willing to work with them to >>>>>> explore >>>>>> what can be done. But what should we propose infra do exactly? I'd like >>>>>> to get a sense of that here with our community first. >>>>>> > >>>>>> > IMO, I don't think a dedicated Environment input field is useful >>>>>> when someone could just as easily type anything pertinent into the >>>>>> description field of a bug report. Less input fields means a simpler >>>>>> JIRA >>>>>> UI -- a good thing IMO. But since it's been used in the past, it may be >>>>>> impossible to actually remove it while keeping the text on old issues. >>>>>> Nonetheless I'm ambivalent if it were to be outright removed and others >>>>>> here want this since I think it's of such low value that data loss >>>>>> wouldn't >>>>>> bother me. >>>>>> > >>>>>> > Can it be retained as a purely read-only on display but otherwise >>>>>> can't edit? I'd like that. >>>>>> > >>>>>> > Perhaps the path of least change and thus "safest" path is for it >>>>>> to be removed from the "Create Issue" screen, yet retain it on other >>>>>> screens for those that are fans of adding/editing it? >>>>>> > >>>>>> > ~ David >>>>>> > -- >>>>>> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker >>>>>> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >>>>>> http://www.solrenterprisesearchserver.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 >>>>> >>>> -- >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >> http://www.solrenterprisesearchserver.com >> >
