How to effectively report an issue on the ADF EMG tracker

[Chris Muir]

As a final post to our recent series in chatting to ADF experts around
using the OTN Forums effectively (http://bit.ly/P2ZD4W) and becoming a
stellar ADF blogger (http://bit.ly/OI1i9o), this time I'd like to
discuss the ADF EMG issue tracker (http://bit.ly/MlYm6g).

In the previous posts we've discussed how to report and write about
issues to get a faster and efficient turnaround. Personally I can't
get enough of these sort of discussions, I'm always willing to learn
how other people do this.

With that in mind I'd like to discuss the ADF EMG issue tracker with
one of it's frequent users Jan Vervecken. In working with the ADF
community for sometime I've always appreciated reading posts from Jan
on the OTN Forums. Jan writes what I think is very detailed and clear
problem description which to the reader makes the issue at hand much
easier to understand and therefore answer.

Returning to ADF EMG issue tracker, I've invited Jan to speak to us
about how he currently uses the ADF EMG issue tracker, to discuss what
guidelines he keeps in mind when posting, how he attempts to
communicate the problem at hand, and hopefully teach members about
this useful service and how to use it efficiently.

Over to you Jan, thanks for your time in participating in the EMG.

[Jan Vervecken]

Thank you Chris.

If you encounter an issue in ADF, you might want it to have a chance to get fixed, and for yourself and others to end up with an improved product [1].
For that to happen you should make the issue identifiable with a focused description, intended for others to understand it.

Often, reporting issues is perceived as hard or time consuming [2], but it should not always be like that.
The ADF EMG issue tracker [3] is intended to lower the barrier on sharing specific (focused) ADF issues, and getting them resolved.

Many of the aspects mentioned in the discussion on how to use the OTN forum effectively [4] also apply to reporting issues, but there is a stronger focus on things being reproducible.

What you might want to end up with for a specific issue are [5]:
- a summary of the problem
- an example application based the HR schema
- steps to reproduce
- specific questions

Starting to write a summary helps to focus on what (you think) is important/relevant for the issue. It is important to keep in mind that others might be looking at your issue from a different perspective, so there should be sufficient context (possibly with references to other resources, like documentation) to enable them to give feedback.

Sometimes it can be as simple as creating a new application in JDeveloper, creating only artifacts that (you think) are relevant to your issue, until you can reproduce the behaviour you have seen before. The smaller/focused such a sample application can be, the easier it is for others to understand and the less chance that feedback will be about irrelevant parts of the code.

Using the sample you created it should be easy to write up the steps to reproduce the observed behaviour. To verify these steps, try them yourself.
To be explicit about what you expect, ask some specific questions. Maybe for a confirmation that others can reproduce the behaviour, or if workarounds exist, or if it is intended behaviour or a bug.

Don't forget that adding screenshots or even a (short) screencast can help to clarify an issue.

Working on describing such an issue can be rewarding in different ways.
If you sufficiently question your own approach for what you are trying to do with ADF, it can help you better understand related aspects of the technology. Searching for related resources or documentation makes you better at that and can bring you to information you did not know of before.
Sometimes it can even resolve your issue before you report it.
The better the issue description/sample/steps, the easier it will be to review feedback you might get.
And if the issue you report gets fixed (in a short or longer term) you will not be the only one who benefits.

- [1] goal/process proposal (gp1)
at http://java.net/projects/adfemg/pages/GoalsAndProcesses
- [2] http://webapplicationdeveloper.blogspot.be/2012/07/adf-tip-rowiterator.html
- [3] http://java.net/jira/browse/ADFEMG
- [4] https://groups.google.com/d/topic/adf-methodology/PzncJBPMFDw/discussion
- [5] e.g. http://java.net/jira/browse/ADFEMG-9

success
Jan Vervecken

[Chris Muir]

Thanks for sharing Jan.

I do have one question for you. I know you must keep track of all the
different enquiries you have with Oracle, be it an ADF EMG tracker
issue, an OTN forum post, a MOS support request and so on, because you
always follow up.

How do you personally keep track of this, and more specifically do you
have or advocate a process for your team to follow too?

CM.

> --
> You received this message because you are subscribed to the ADF
> Enterprise Methodology Group
> (http://groups.google.com/group/adf-methodology). To unsubscribe send
> email to adf-methodolo...@googlegroups.com
>
> All content to the ADF EMG lies under the Creative Commons Attribution
> 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any
> content sourced must be attributed back to the ADF EMG with a link to
> the Google Group (http://groups.google.com/group/adf-methodology).

[Jan Vervecken]

Thanks Chris.

Depending on the project/customer that issue is related to, a direct link to the OTN forum post or ADFEMG JIRA issue will most likely end up in some kind of issue tracking tool used for the project.

All these tools have features to allow you to know about issue changes (most send e-mail, including the OTN forum, the ADFEMG JIRA, and My Oracle Support).
Whether to follow up or ignore such issue changes is just a matter of choice.

So, other than "keep it simple", no process suggestions here.

regards
Jan Vervecken

> email to adf-methodology+unsubscribe@googlegroups.com

[John Stegeman]

It may seem pedantic or silly of me to say so, but (and this also applies to Jan's posts on the OTN forums as well) saying "please" and "thank you" is something that Jan always does, and it always makes me want to respond :)

[Jan Vervecken]

Thanks for your reply John. ;-)

regards
Jan Vervecken