root wrote: > On Tue, Apr 1, 2008 at 10:39 AM, Ed Murphy <[EMAIL PROTECTED]> wrote: >> As for complexity, I've >> already pointed out how the old system (under which the individual >> significance of an individual action could be determined immediately) >> is simpler than the new (in which it cannot be determined until the >> panel acts); > > Because there are no individual actions that are significant. > Agreement between panel members is a status, not an action.
Individual actions /are/ significant, whether or not they are entered into the database individually or not. See CFJ 1908. >> I've also already pointed out how my proposed >> revision is driven not just by the state of the automation, but also by >> the concept of partial continuity (deliberately choosing a panel with >> some members in common with the previous one). > > You can do that with the current system as well. All it lacks is the > notion of individual recusal, and I'm not convinced that we need that. > There's no reason to flip a nonperforming panelist to supine when you > can just avoid assigning the panels e is on. You can get that effect, but why not actually call it what it is? I'm willing to move individual recusal to a separate proposal (you're right, competence to judge appeals is a higher bar than competence to judge cases in general, because appeals imply controversy). >> Furthermore, the >> existing concept of panels existing independently of cases is confusing. > > More confusing than having to inspect the entire case history in order > to determine what panels exist? No, but the proposed revision would eliminate both. >> Redeveloping the database is not in the cards. If the proposed rule >> revision is voted down, then I can simply enter recusal records for all >> three members individually, rather than just the ones who aren't members >> of the new panel. > > Redeveloping the database may be infeasible, but would it be possible > to, e.g., add a "recuse panel" script that recuses all three members > simultaneously, and modify the case templates to interpret > simultaneous recusal as panel recusal? Adding a "recuse panel" script is no big deal, compared to just using the existing "recuse" script three times (it's not difficult, just tedious). I'll think about revising the PHP interpretation code based on how the rest of this discussion plays out. >> I may also switch to a policy of either supporting >> majority opinions pre-emptively, or assigning completely new panels when >> the members of the old panel fail to request such support. > > Ugh. That's my opinion of the 13 messages still sitting in my "stuff that may support a panel action" folders (most of them are probably obsolete by now, actually). Oh, that reminds me, I'm late on assigning prerogatives again. Will take care of that shortly.
