> Ok, but this RFE was previously accepted and slated to be implemented in a > future release. In other words according to the notes it had "made the cut".
Not exactly. 99.9% of the time, RFE's are not "accepted" - they are put "Under Consideration". That means the RFE will be considered during the release planning of the listed targeted release - but does not necessarily mean it will be implemented. More RFEs are placed "Under Consideration" than get into any given release and thus RFEs that cannot be implemented due to technology limitations, conflicting business priorities or time restraints can be further deferred. Think of it somewhat like elimination rounds in a game show. If the initial RFE submission is placed "under consideration", that means the review committee felt it was a reasonable idea and that it could go on to be assessed during the planning stage of the targeted release. If, during the planning stage, the RFE is found to meet the criteria for inclusion in the release, then it will be scoped further and tentatively placed into the backlog for that release. If all goes well, it gets into the release - but changes in priority always happen and even once it's in the backlog for the release, there's still a chance that something of higher priority may defer it to a later release. If it's deferred to a later release, it will be reviewed again during that future planning session and the cycle continues. We try to be very explicit about these facts in communication with customers so that we "stay cool" with their expectations. The RFE process, for example, is found here: http://www.bmc.com/support/review-policies and documents what the various statuses mean. -David J. Easter Sr. Product Manager, Solution Strategy and Development BMC Software, Inc. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Timothy Powell Sent: Monday, December 07, 2009 11:29 AM To: arslist@ARSLIST.ORG Subject: Re: Change Diary Field Font Ok, but this RFE was previously accepted and slated to be implemented in a future release. In other words according to the notes it had "made the cut". Now if it truly DIDN'T make the cut, then I would have expected somebody to inform me. Closing previously accepted AND approved RFEs merely due to age = not cool. BTW, bell was rung. It was confirmed that the RFE was closed merely because of age. RFE has been re-opened under a new number. Tim Powell -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Easter, David Sent: Friday, December 04, 2009 2:05 PM To: arslist@ARSLIST.ORG Subject: Re: Change Diary Field Font > So I guess I need to ring somebody's bell and see why they decided to close it when was "outstanding for a long time" due to BMC not implementing it. Just to follow up on this, BMC tends to be aggressive in closing RFEs that have not been implemented across multiple release vehicles. In other words, if an RFE is logged against version 2.0, was not accepted for implementation in version 3.0 or 4.0, and isn't expected to make it into 5.0; it is a strong candidate for just closing it. This is done in an effort to be honest with those logging the RFE that it has not "made the cut" several times and therefore is not very likely to ever be implemented as described. For example, this RFE was submitted in June of 2005. It was closed in February of 2009 - about 4 years later. There are pros and cons to leaving RFEs open forever, which I'm not going to debate here, but I'm just letting you know why RFEs get closed even though they were originally excepted but not implemented. Even though a specific RFE is closed, the general capability might be part of a larger theme or broad enhancement found in a future release. Product Management does take into account smaller and historic "point" RFEs when making larger decisions around product direction - even if the point RFE had been closed as no plans to implement within a particular time period. For example, were a broader move made in a future release to support Rich Text or HTML formatting in character based fields, and that would subsume both this and other such "formatting" RFEs logged over the years. -David J. Easter Sr. Product Manager, Solution Strategy and Development BMC Software, Inc. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Timothy Powell Sent: Wednesday, December 02, 2009 10:45 AM To: arslist@ARSLIST.ORG Subject: Re: Change Diary Field Font Here is the latest on the RFE: **************** Regarding: RFE0009445, at 2/3/2009 2:58:05 PM, created by xxxxx Hi , We have reevaluated this RFE and since it's been outstanding for a long time, we feel that this RFE won't be practical for us to implement now. ******************* So I guess I need to ring somebody's bell and see why they decided to close it when was "outstanding for a long time" due to BMC not implementing it. Tim On Wed, 2009-12-02 at 12:43 -0500, Carey Matthew Black wrote: > I think this could be done in the v7.1 Mid-Tier with a custom CSS for the field. > I also think the v6.3's Mid-Tier could also be customized (with more > effort, but in a similar way) too. > > However for the User Tool I think we are out of luck for the kind of > specific (single field) font change. > > > However, as a form of workarounds... > > ) Maybe the text could be converted to a View field and displayed > with specific font settings in that display. It may not be trivial to > implement, but I think it could be done. > > ) Another approach would be to give the users a "report" button that > would preview the field's content. So that the effort the user needs > to take to see the fixed width content is reduced to a single button > click. > > Just a few thoughts. > ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are" ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
