Uncle.

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of Easter, David
Sent: Monday, December 07, 2009 4:21 PM
To: [email protected]
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".

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:[email protected]] On Behalf Of Timothy Powell
Sent: Monday, December 07, 2009 11:29 AM
To: [email protected]
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:[email protected]] On Behalf Of Easter, David
Sent: Friday, December 04, 2009 2:05 PM
To: [email protected]
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:[email protected]] On Behalf Of Timothy Powell
Sent: Wednesday, December 02, 2009 10:45 AM
To: [email protected]
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:[email protected] ARSlist: "Where the Answers Are"

____________________________________________________________________________
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"

____________________________________________________________________________
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"

____________________________________________________________________________
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"

Reply via email to