Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Eclipse OCL Newsgroup Netiquette for Problem queries
Remember that you are asking for free advice, so as a courtesy to anyone who answers, you should try hard to express your problem clearly. This will often benefit you since you may get a useful answer without a game of ping-pong to uncover the detail.
If you think your problem is simple, you may try to just ask a simple question, with a few cut and paste lines or a screenshot.
However if your problem is not simple expect to provide:
- a small zipped project that demonstrates the problem
- a clear description of what you actually observe (ideally a stack trace, but perhaps a screenshot)
- a clear description of what you hoped to observe
- clear instructions on how to cause what you observe to happen
- preferably a launch configuration saved as part of the zipped project using the Run->Run Configurations...->Common Tab Shared file location.
- the version number of Eclipse OCL
- e.g. the plugin id of org.eclipse.ocl.ecore if using the Classic Eclipse OCL
- e.g. the plugin id of org.eclipse.ocl.examples.pivot if using the new Pivot Eclipse OCL
- the version number of Eclipse; e.g Kepler SR1, Luna M1
Yes, it is a pain to provide this information, but if you don't whoever tries to help you will have to recreate your problem scenario by guessing at the missing information. This is really irritating and time consuming, particularly when the guesses prove to be wrong. If you provide bad information, you can look forward to playing ping-pong for over a week with slower responses each time. If you provide good information you may get a useful answer first time. Your choice. Help yourself.
Screenshots are helpful for showing unexpected things on the screen. They are NEVER useful as a way of communicating EMF models or Java; that is what text is for!
The newsgroup/forum is a shared resource, so make it useful. Use Message titles that may help others to discover the answer to your problem.
e.g. How do I customize the message resulting from an invariant failure?
- NOT: Newbie OCL question. (We know it's about OCL and we realize you're a newbie pretty rapidly too.)
If you do not get any response to your query, feel free to 'ping' the thread after a couple of days; sometimes messages accidentally get marked as read; too many distractions.
Rationale for not relying on telepathy
The most informed responses will often come from developers who may be working one or two years ahead of the release that you are using. Their workspaces are set up for the current code so they will naturally try to reproduce on the current code first. Creating an accurate legacy workspace takes extra time.
If you don't identify your software versions, the developers may be confused by problems they don't see and may give misleading answers for your version.
If you don't identify what doesn't work, respondents are forced to guess at whether you get a pop up, compilation error, a stack trace, error log or system failure, each of which conveys extra information that is almost certainly helpful to the respondent even if it is annoying gibberish to you.
If you don't provide an executable repro project and the problem is non-trivial, the respondents have to spend time recreating your problem environment, and may well do so incorrectly wasting everyone's time.
If you don't provide a launch configuration or clear activation instructions, the respondents must guess at how to reproduce your problem. Again incorrect guesses waste everyone's time.
A less obvious benefit of a repro is that it gives developers an insight into the sometimes magical things that real users do and the problems that may result. It may also remind developers of problems that they have previously encountered. These insights and reminders may motivate improved diagnosis of problems.