HowTo:POV-Ray Feature Requests - Revision history

Wfpokorny: Update note related to Flyspray to Github issue migration.

2018-01-04T18:19:30Z

Update note related to Flyspray to Github issue migration.

Wfpokorny: Updating this section for github issues over our older FlySpray issue tracker.

2016-11-19T12:39:35Z

Updating this section for github issues over our older FlySpray issue tracker.

SharkD: moved Knowledgebase:POV-Ray Feature Requests to HowTo:POV-Ray Feature Requests: Scope of article falls more in the "How To" department, at least when compared to the "How to make a bug report article".

2010-07-26T15:55:18Z

moved Knowledgebase:POV-Ray Feature Requests to HowTo:POV-Ray Feature Requests: Scope of article falls more in the "How To" department, at least when compared to the "How to make a bug report article".

SharkD: extra word

2010-06-25T21:27:28Z

extra word

SharkD: add a point

2010-06-25T21:24:41Z

add a point

SharkD: wording

2010-06-25T21:22:54Z

wording

SharkD: Undo revision 2742 by SharkD (Talk)undo

2010-06-25T21:20:21Z

Undo revision 2742 by SharkD (Talk)undo

SharkD: put the first comment of advice into the list as well

2010-06-25T21:17:33Z

put the first comment of advice into the list as well

SharkD: "would">"might", since the idea was made as a suggestion

2010-06-25T21:14:54Z

"would">"might", since the idea was made as a suggestion

SharkD: grammar

2010-06-25T21:13:55Z

grammar

@@ Line 1: / Line 1: @@
 We all want to see POV-Ray improved, and from time to time it may occur to us that there's a feature that we would like to see, or something we'd like to see improved. The proper place for "feature wishlists" is the bugtracking and feature-request system on [https://github.com/POV-Ray/povray/issues Github], as that's ''the'' primary place where the developers will look for them.
-<p class="Note"><strong>Note:</strong> We are in the process of porting issues still open in our previous [http://bugs.povray.org/ FlySpray System] to the new
+<p class="Note"><strong>Note:</strong> All issues still open in our previous [http://bugs.povray.org/ FlySpray Bug Reporting System] have been ported to the new [https://github.com/POV-Ray/povray/issues Github Issue Tracking System]. Please exclusively use Github for new issues and updates to open issues.</p>
 When ''making'' feature requests, a word of advice:

@@ Line 1: / Line 1: @@
-We all want to see POV-Ray improved, and from time to time it may occur to us that there's a feature that we would like to see, or something we'd like to see improved. The proper place for "feature wishlists" is the bugtracking and feature-request system on [http://bugs.povray.org/ Bugtracker], as that's ''the'' primary place where the developers will look for them.
+We all want to see POV-Ray improved, and from time to time it may occur to us that there's a feature that we would like to see, or something we'd like to see improved. The proper place for "feature wishlists" is the bugtracking and feature-request system on [https://github.com/POV-Ray/povray/issues Github], as that's ''the'' primary place where the developers will look for them.
-To see a list of current feature requests, whether open or closed, visit [http://bugs.povray.org/index.php?string=&project=2&search_name=&type%5B%5D=2&sev%5B%5D=&pri%5B%5D=&due%5B%5D=&reported%5B%5D=&cat%5B%5D=&status%5B%5D=&percent%5B%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=&do=index this link]. The bugtracker also provides a means for users to vote on bugs or features they deem particularly important to address.
+<p class="Note"><strong>Note:</strong> We are in the process of porting issues still open in our previous [http://bugs.povray.org/ FlySpray System] to the new
 When ''making'' feature requests, a word of advice:
-Please ''do'' read [[HowTo:Make A Bug Report]] and [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively] before submitting any entries to the bugtracker, and ''do'' heed the advice presented there. There is a reason the first is referenced at the top of each and every bugtracker page, and the second in turn is referenced in by the first: By following those rules - or at least keeping them in mind as you file bug reports - you make life a lot easier for the people you expect to fix the issues.
+Please ''do'' read [[HowTo:Make A Bug Report]] and [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively] before submitting any entries to the issue tracker, and ''do'' heed the advice presented there. By following those rules - or at least keeping them in mind as you file issues - you make life a lot easier for the people you hope to address the issues.
 Some other points raised in [http://news.povray.org/povray.advanced-users/thread/%3C4c1d52c5%241%40news.povray.org%3E/] and [http://news.povray.org/povray.general/thread/%3C4c09591e%241%40news.povray.org%3E/]:
@@ Line 11: / Line 12: @@
 * If discussion of a feature request has resulted in a summary or conclusion that differs from the original request, a new feature request should not be made. Instead, the existing one should be changed. This implies contributing ideas to the feature request discussion, and then coming up with a single coherent idea, not leaving it at two half-finished ideas.
 * Closely-related feature requests should be grouped together; e.g. requests for Windows UI enhancements with respect to the editor such as "Delete", "Reload" and "Rename" commands could reasonably be put into a single request (all at once or via editing a bug later).
-* There is a feature to allow other users and/or developers to comment on bugs & feature requests on bugtracker, but this is primarily intended for providing additional information, or feedback on the current status. For proper discussions, it lacks the necessary publicity. (When was the last time anyone just browsed the bugtracker just to see if there was some interesting discussion going on in some of the entries?) The POV-Ray community is strongest in the newsgroups. That said, the problem with ''discussions'' about feature requests is that they tend to have ''no'' clear-cut result whatsoever, as they tend do be free brainstorming sessions - unless there's someone with the necessary will and authority (e.g. because he has started the discussion in the first place) "driving" the discussion to a proper conclusion (ideally by summarizing the discussion and result in a proper place). In situations like these, bugtracker excels.
+* There is a feature to allow other users and/or developers to comment on bugs & feature requests on github, but this is primarily intended for providing additional information, or feedback on the current status. For proper discussions, it lacks the necessary publicity. (When was the last time anyone just browsed the github just to see if there was some interesting discussion going on in some of the entries?) The POV-Ray community is strongest in the newsgroups. That said, the problem with ''discussions'' about feature requests is that they tend to have ''no'' clear-cut result whatsoever, as they tend do be free brainstorming sessions - unless there's someone with the necessary will and authority (e.g. because he has started the discussion in the first place) "driving" the discussion to a proper conclusion (ideally by summarizing the discussion and result in a proper place). In situations like these, github excels.
 * A sensible rule for opening a new feature request might then be that it must be discussed in the newsgroups first, to weed out crackpot ideas and to refine ideas by feedback from what users actually need. After discussion, the request should only be entered if a member of the POV-Ray team deems the request reasonable (note that a request should not be deemed unreasonable at this point just because it would be too much effort to implement right now).
-* Excessive use/misuse of the newsgroups and bugtracker may be considered "vandalism".
+* Excessive use/misuse of the newsgroups and github may be considered "vandalism".

@@ Line 10: / Line 10: @@
 * If discussion of a feature request has resulted in a summary or conclusion that differs from the original request, a new feature request should not be made. Instead, the existing one should be changed. This implies contributing ideas to the feature request discussion, and then coming up with a single coherent idea, not leaving it at two half-finished ideas.
-* Closely-related feature requests should be grouped together; e.g. requests for Windows UI enhancements with respect to the editor could such as "Delete", "Reload" and "Rename" commands could reasonably be put into a single request (all at once or via editing a bug later).
+* Closely-related feature requests should be grouped together; e.g. requests for Windows UI enhancements with respect to the editor such as "Delete", "Reload" and "Rename" commands could reasonably be put into a single request (all at once or via editing a bug later).
 * There is a feature to allow other users and/or developers to comment on bugs & feature requests on bugtracker, but this is primarily intended for providing additional information, or feedback on the current status. For proper discussions, it lacks the necessary publicity. (When was the last time anyone just browsed the bugtracker just to see if there was some interesting discussion going on in some of the entries?) The POV-Ray community is strongest in the newsgroups. That said, the problem with ''discussions'' about feature requests is that they tend to have ''no'' clear-cut result whatsoever, as they tend do be free brainstorming sessions - unless there's someone with the necessary will and authority (e.g. because he has started the discussion in the first place) "driving" the discussion to a proper conclusion (ideally by summarizing the discussion and result in a proper place). In situations like these, bugtracker excels.
 * A sensible rule for opening a new feature request might then be that it must be discussed in the newsgroups first, to weed out crackpot ideas and to refine ideas by feedback from what users actually need. After discussion, the request should only be entered if a member of the POV-Ray team deems the request reasonable (note that a request should not be deemed unreasonable at this point just because it would be too much effort to implement right now).
 * Excessive use/misuse of the newsgroups and bugtracker may be considered "vandalism".

← Older revision		Revision as of 21:24, 25 June 2010
Line 13:		Line 13:
	* There is a feature to allow other users and/or developers to comment on bugs & feature requests on bugtracker, but this is primarily intended for providing additional information, or feedback on the current status. For proper discussions, it lacks the necessary publicity. (When was the last time anyone just browsed the bugtracker just to see if there was some interesting discussion going on in some of the entries?) The POV-Ray community is strongest in the newsgroups. That said, the problem with ''discussions'' about feature requests is that they tend to have ''no'' clear-cut result whatsoever, as they tend do be free brainstorming sessions - unless there's someone with the necessary will and authority (e.g. because he has started the discussion in the first place) "driving" the discussion to a proper conclusion (ideally by summarizing the discussion and result in a proper place). In situations like these, bugtracker excels.		* There is a feature to allow other users and/or developers to comment on bugs & feature requests on bugtracker, but this is primarily intended for providing additional information, or feedback on the current status. For proper discussions, it lacks the necessary publicity. (When was the last time anyone just browsed the bugtracker just to see if there was some interesting discussion going on in some of the entries?) The POV-Ray community is strongest in the newsgroups. That said, the problem with ''discussions'' about feature requests is that they tend to have ''no'' clear-cut result whatsoever, as they tend do be free brainstorming sessions - unless there's someone with the necessary will and authority (e.g. because he has started the discussion in the first place) "driving" the discussion to a proper conclusion (ideally by summarizing the discussion and result in a proper place). In situations like these, bugtracker excels.
	* A sensible rule for opening a new feature request might then be that it must be discussed in the newsgroups first, to weed out crackpot ideas and to refine ideas by feedback from what users actually need. After discussion, the request should only be entered if a member of the POV-Ray team deems the request reasonable (note that a request should not be deemed unreasonable at this point just because it would be too much effort to implement right now).		* A sensible rule for opening a new feature request might then be that it must be discussed in the newsgroups first, to weed out crackpot ideas and to refine ideas by feedback from what users actually need. After discussion, the request should only be entered if a member of the POV-Ray team deems the request reasonable (note that a request should not be deemed unreasonable at this point just because it would be too much effort to implement right now).
		+	* Excessive use/misuse of the newsgroups and bugtracker may be considered "vandalism".

@@ Line 11: / Line 11: @@
 * If discussion of a feature request has resulted in a summary or conclusion that differs from the original request, a new feature request should not be made. Instead, the existing one should be changed. This implies contributing ideas to the feature request discussion, and then coming up with a single coherent idea, not leaving it at two half-finished ideas.
 * Closely-related feature requests should be grouped together; e.g. requests for Windows UI enhancements with respect to the editor could such as "Delete", "Reload" and "Rename" commands could reasonably be put into a single request (all at once or via editing a bug later).
-* There is a feature to allow other users and/or developers to comment on bugs & feature requests on bugtracker, but this is primarily intended for providing additional information, or feedback on the current status. For proper discussions, it lacks the necessary publicity. (When was the last time anyone just browsed the bugtracker just to see if there was some interesting discussion going on in some of the entries?) The POV-Ray community is strongest in the newsgroups. That said, the problem with ''discussions'' about feature requests is that they tend to have ''no'' clear-cut result whatsoever, as they tend do be free brainstorming sessions - unless there's someone with the necessary will and authority (e.g. because he has started the discussion in the first place) "driving" the discussion to a proper conclusion (ideally by summarizing the discussion and result in a proper place). In this situation, bugtracker excels.
+* There is a feature to allow other users and/or developers to comment on bugs & feature requests on bugtracker, but this is primarily intended for providing additional information, or feedback on the current status. For proper discussions, it lacks the necessary publicity. (When was the last time anyone just browsed the bugtracker just to see if there was some interesting discussion going on in some of the entries?) The POV-Ray community is strongest in the newsgroups. That said, the problem with ''discussions'' about feature requests is that they tend to have ''no'' clear-cut result whatsoever, as they tend do be free brainstorming sessions - unless there's someone with the necessary will and authority (e.g. because he has started the discussion in the first place) "driving" the discussion to a proper conclusion (ideally by summarizing the discussion and result in a proper place). In situations like these, bugtracker excels.
 * A sensible rule for opening a new feature request might then be that it must be discussed in the newsgroups first, to weed out crackpot ideas and to refine ideas by feedback from what users actually need. After discussion, the request should only be entered if a member of the POV-Ray team deems the request reasonable (note that a request should not be deemed unreasonable at this point just because it would be too much effort to implement right now).

← Older revision	Revision as of 15:55, 26 July 2010
(No difference)