Best way to use sourceforge tickets
A Logo programming environment for Microsoft Windows
Brought to you by:
david_costanzo
Menu
▾
▴
#33 Best way to use sourceforge tickets
Well, I have to admit that I|m not a sourceforge expert. So perhaps I sometimes run into problems of using it the right way.
I must have created feature request #131 once upon a time, but it's no longer there.
So I got me a download of the whole FMSLogo changelog and found out that the problem must have been solved by implementing the feature (extending MACHINE by two Scrollbar options) already in 8.3.0.
I'm very grateful for that because it supports very well a still pending and still important project of ours called copter.
Nevertheless I did not notice the implementation, because I had directly jumped to 8.3.1+.
So yesterday I created a feature request to report that I now found the new feature in 8.3.2 without a mention of it as a new implementation. This has been accepted for the moment as request 133, but has disappeared immediately, probably because the feature was already implemented.
I should have seen it earlier already in 8.3.0. So it's a good thing having the changelog as a whole.
As a side information I had told that I had to interrupt our work with FMSLogo for more than half a year, but that now it has been resumed.
Considering the long way I went with FMSLogo together with my partners this should be an important information, too, because I still have structured plans how to go on with it in the future, and there are partners involved.
But I don't know how to convey informations like this within the framework of Sourceforge effectively.
So, what is your idea to discuss future concepts concerning FMSLogo in a proper and effective way, especially if structural and sometimes even stategic problems are involved?
Good question.
You might not see the MACHINE feature request because the default filter only shows open bugs/features. You can change the filter to include tickets that have been closed. Or you can search for it.
As for the conventions:
A bug ticket is for a single thing that FMSLogo claims to do but doesn't do. Please try to reproduce on the latest version and search for duplicates before opening one. Any discussion on the ticket should be limited to the bug.
A feature request ticket is for a single thing that FMSLogo doesn't claim to do but that you want it to do. The best feature requests include what you're trying to accomplish at a high level, because there may be many ways to accomplish what you want, not just the way you have in mind. Any discussion on the ticket should be limited to the feature request.
A support request ticket is for something that FMSLogo can do but that for some reason, you can't figure out how to make it work.
For each of the three types of tickets, the description should be written in a way that it can be "completed". That is, the tickets should not be open-ended or exploratory.
The Open Discussion is for everything else. This would include updates on pbreport, ideas about how FMSLogo should be used, or other things for the community (not necessary the developers). It could also include talking about that you're not sure is a bug or a feature request. People don't even need a SourceForge account to post to Open Discussion.
Direct, private messages should never be used.
Anyway, that's what I had in mind when I set things up. I'm not strict because people with good intentions don't deserve to be yelled at for not following a process that they don't even know exists.
Now that I've said all this stuff, I may close some of your tickets that don't follow these conventions (the ones that I've kept open only so as not to offend you).