On 6/5/2010 3:00 PM, Jim Holsenback wrote:
> ...If discussion and
> list building is what your aim is, how about
> povray.pov4.discussion.general ... are we getting any closer ;-)

Where they will get buried once again... There needs to be a place where 
the /result/ of the discussion can be recorded. A log or some such. One 
where other information like bug reports aren't mixed in.


-- 
http://isometricland.com

Post a reply to this message

On 06/05/2010 11:41 PM, SharkD wrote:
> On 6/4/2010 4:47 PM, Jim Holsenback wrote:
>> concur ... moved it into User:SharkD ... besides some of what you
>> requested is already implemented
> 
> Which ones were implemented?
> 
> 
> 
Hmmmm ... I thought I was fairly clear with the posting I left in your
user space on the Wiki. You haven't been test driving the beta's have
you? Off the top of my head ... there is now a #for loop, and #break now
allows you to bail out of loops. The former was a new addition, and the
later was the result of a bug that I found by accident (a typo). As for
the various unary/binary operators, I noted that some not all that you
mentioned have been around for quite a while now. I'd be the first to
admit that some portions of the documentation can be rather dry reading,
but if you do some digging there is some useful information to be found ;-)

Post a reply to this message

On 06/05/2010 11:43 PM, SharkD wrote:
> On 6/5/2010 3:00 PM, Jim Holsenback wrote:
>> ...If discussion and
>> list building is what your aim is, how about
>> povray.pov4.discussion.general ... are we getting any closer ;-)
> 
> Where they will get buried once again... There needs to be a place where
> the /result/ of the discussion can be recorded. A log or some such. One
> where other information like bug reports aren't mixed in.
> 
> 

clipka pointed out the attributes of the bugtracker so I won't go over
that again. I really don't think that the KB namespace on the Wiki is a
sound choice, and the link to your post in the Questions and Tips table
of contents wasn't that prudent of a choice either. That leaves your
user space ... list away if you must, but I think the bugtracker is the
best choice :-)

Post a reply to this message

Am 06.06.2010 04:43, schrieb SharkD:
> On 6/5/2010 3:00 PM, Jim Holsenback wrote:
>> ...If discussion and
>> list building is what your aim is, how about
>> povray.pov4.discussion.general ... are we getting any closer ;-)
>
> Where they will get buried once again... There needs to be a place where
> the /result/ of the discussion can be recorded. A log or some such. One
> where other information like bug reports aren't mixed in.

Any feature request that does not wind up in the bugtracker /will/ get 
buried.

And 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... like, say, 
the bugtracker ;-))

(Yes, the feature request description is a good place to summarize 
earlier discussions.)

Post a reply to this message

Again, I think it would be good to have a formal means of discussing and 
tracking feature requests for non-devs, since bugtracker seems to be 
"for devs only."

My reasoning is that feature requests are hidden once they are closed on 
bugtracker, so there's no obvious way to view them. There's also no way 
to discuss them further since discussions are closed once the request is 
locked.

This is definitely not a method that is amenable to users.

-- 
http://isometricland.com

Post a reply to this message

Am 20.06.2010 10:10, schrieb SharkD:
> Again, I think it would be good to have a formal means of discussing and
> tracking feature requests for non-devs, since bugtracker seems to be
> "for devs only."
>
> My reasoning is that feature requests are hidden once they are closed on
> bugtracker, so there's no obvious way to view them. There's also no way
> to discuss them further since discussions are closed once the request is
> locked.
>
> This is definitely not a method that is amenable to users.

Yes, I do agree that this practical attempt at what sounded good in 
theory did show some serious caveats of that process.

I don't think the way things were handled was the right way to handle 
them, but extrapolating from this experience, my idea of the process may 
be less universal than I had imagined; and similar outcomes may have to 
be expected in future, too.

My apologies for the inconvenience.

Post a reply to this message

On 6/20/2010 9:51 AM, clipka wrote:
> Am 20.06.2010 10:10, schrieb SharkD:
>> Again, I think it would be good to have a formal means of discussing and
>> tracking feature requests for non-devs, since bugtracker seems to be
>> "for devs only."
>>
>> My reasoning is that feature requests are hidden once they are closed on
>> bugtracker, so there's no obvious way to view them. There's also no way
>> to discuss them further since discussions are closed once the request is
>> locked.
>>
>> This is definitely not a method that is amenable to users.
>
> Yes, I do agree that this practical attempt at what sounded good in
> theory did show some serious caveats of that process.
>
> I don't think the way things were handled was the right way to handle
> them, but extrapolating from this experience, my idea of the process may
> be less universal than I had imagined; and similar outcomes may have to
> be expected in future, too.
>
> My apologies for the inconvenience.
Just going to drop a comment here. For POVRay, a "democratic" vote on 
feature thing may sort of work. Linden Labs uses the same system for 
their bug/feature tracker, and its gotten to be so much of a horrible 
swamp that even finding "if" something has been suggested, so you can 
vote, or comment, never mind do so before something gets closed,or 
relocated, or incorrectly marked as fixed (this happens a bit too often 
in some cases, sometimes due to a "we think we had a fix pending, only 
it didn't work, but no one bothered to reopen the issue, when it 
failed", or just lost in the mire. My opinion of such systems is, as a 
result... rather jaded. lol Not sure, reading the posts on the subject, 
over the last 24 hours, is impressing me with it here either. Seems like 
we are seeing the same sort of issues, "I think my suggestion still 
needs time to be commented on, but someone closed it.", sort of thing. 
Don't make the same mistakes Linden has.

-- 
void main () {
   If Schrödingers_cat is alive or version > 98 {
     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

clipka wrote:

> Yes, I do agree that this practical attempt at what sounded good in 
> theory did show some serious caveats of that process.

I think the basic idea is reasonable so if there are problems
with the process the way to go may be to simply tweak the process.
Here are my 2 cents on that:

1. The POV-Ray community is strong in the forum so I think
    that would be the best place for discussing (not tracking)
    new feature suggestions.

2. The bug tracker could be officially extended to also track
    feature requests (although you can currently add them, this
    is not described or commented on anywhere). A sensible rule
    for opening a new feature request would 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.

3. 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).

4. This process only works if each feature request in the newsgroups
    actually gets read by member of the POV team, so it might be useful
    to add a new group povray.feature-requests or similar.

5. The feature request entry should link back to the newsgroup thread
    discussing the feature request, and a link to the new task should be
    posted on the thread as a notification.

6. Once a feature request is added it must remain visible whatever
    state it is set to. I have no experience with Flyspray but I'd
    expect there to be some configuration/solution for this.

Post a reply to this message

On 6/20/2010 4:38 PM, Patrick Elliott wrote:
> Just going to drop a comment here. For POVRay, a "democratic" vote on
> feature thing may sort of work. Linden Labs uses the same system for
> their bug/feature tracker, and its gotten to be so much of a horrible
> swamp that even finding "if" something has been suggested, so you can
> vote, or comment, never mind do so before something gets closed,or
> relocated, or incorrectly marked as fixed (this happens a bit too often
> in some cases, sometimes due to a "we think we had a fix pending, only
> it didn't work, but no one bothered to reopen the issue, when it
> failed", or just lost in the mire. My opinion of such systems is, as a
> result... rather jaded. lol Not sure, reading the posts on the subject,
> over the last 24 hours, is impressing me with it here either. Seems like
> we are seeing the same sort of issues, "I think my suggestion still
> needs time to be commented on, but someone closed it.", sort of thing.
> Don't make the same mistakes Linden has.
>

I would just like to clarify that I'm not advocating a "democratic" way 
of choosing which features should and should not be implemented, or 
which are that most critical. I just want a way to track and discuss 
ideas that isn't subject to being "blocked" or "locked" on some dev's whim.


-- 
http://isometricland.com

Post a reply to this message

On 21.06.10 01:04, Christian Froeschlin wrote:
> 3. 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).

That was my understanding of what clipka has previously suggested in this 
thread already:

 >> And 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... like, say,
 >> the bugtracker ;-))
 >>
 >> (Yes, the feature request description is a good place to summarize
 >> earlier discussions.)

	Thorsten

Post a reply to this message