On Saturday, August 7, 2004, at 04:39 PM, Ken Causey wrote:

> On Sat, 2004-08-07 at 12:56, Doug Way wrote:
>
>> Actually, I've needed the same capability for moving an [approved] 
>> item
>> back to Review status.  There are several groups under Approved right
>> now (at the bottom of the list) that have some issue and should go 
>> back
>> to Review.  We could probably also handle this with a [reopened] tag.
>
> Maybe we should just implement a set of tags that re-categorize a
> group.  're-reviewed', 're-approved', 're-update', 're-unreviewed'?
> That might be going overboard but you get the idea.

True, although I don't think we need re-approved and re-update.  If 
something goes back to review, then a simple [approved] or [update - 
xxxx] can still move it to Approved/Update.  (Even if it's the second 
time it's approved... it's the order that matters.)

I'm not sure we really need re-unreviewed, either.  (Although I 
wouldn't have a big problem with allowing it.)  Right now, everything 
in Unreviewed has had no discussion whatsoever, which would not really 
be true for something bumped back from a different status.

So if we're only left with 're-reviewed', we could just call it 
'reopened'.  Although 're-reviewed' is okay with me too.


>> I guess support for a new [reopened] tag also needs to be added to the
>> BFAV server.  (I'm not quite sure why the BFAV server has to know 
>> about
>> all the tags... I guess this is for performance reasons?)
>
> The BFAV server knows about the tag so that the text processing work 
> has
> to only be done once.  This was a large part of the speed improvement
> between BFAV and BFAV2.  It doesn't of course have to know what the 
> tags
> mean, it just has to know what category the tag is and what bitmask it
> maps to.  A few minutes work basically.

Ah, cool.

>> Another BFAV improvement which is really needed is some sort of 
>> website
>> which shows the current status of all fixes/enhancements for the last
>> month, similar to Bert's old sqfixes site, so everyone has a 
>> quick/easy
>> place to check what the status of something is.  I already emailed
>> about that privately... I wanted to work on this after 3.7 is released
>> if no one else gets to it.
>
> I would be willing to look into this.  However I've been burned rather
> badly in a couple of cases in the last couple of years putting in a lot
> of time on projects to then get no reaction, good, bad, or otherwise.  
> I
> would only really be willing to do this if I'm presented with a clear
> design that the community in some fashion agrees will provide the
> desired functionality.

I think it should be relatively easy to get some consensus on this, 
I'll try to come up with an example and see what people think.  Also 
I'll try to keep it simple enough so that it's easy to implement.

>> Merging groups together would be more difficult with the current
>> system... I know Ken has talked about eventually replacing the
>> emailed-based server with something more robust.
>
> I spent quite a bit of time a few months ago looking into this.  But I
> hit a wall on security.  Its amazing really how much safety is built
> into the current system just due to the fact that it is an 
> 'append-only'
> system.  There's never any case in which information can be lost or
> overwritten.  Implementing anything as safe in an object database model
> looked to be difficult.  That wasn't the only reason I stopped, but it
> certainly slowed me down.
>
> Again I would be willing to look at this again if the community as a
> whole could come to some sort of a consensus as to what they would
> really want out of such a system.

Yeah, I think it would be more difficult to come to a consensus on 
this, and it's not particularly urgent.  The current append-only system 
has its advantages.

> ...  On the harvesting issue I found
> Michael's reminder of the dual update stream interesting.

Will reply about this in more detail tomorrow.

- Doug