Re: re-categorizing
Thanks, everybody, for working together on this!
Andreas, please comment on my assertions about blends metapackages, or
point to some text we need to read.
On Thu, 2009-03-12 at 23:47 -0200, Barbara Figueirido wrote:
> Hello all!
>
> I support your re-categorization proposals, Elaine!
>
> I would like to add a couple of things, if you don't mind.
>
> - I would keep the distinction between "legal office administration" and
> "court administration", since though similar in their needs, there might
> be some nuances that make them somewhat incompatible, I would think (I
> am not totally sure of this, maybe some exchange is necessary on this
> subject). I think that a 'legal' Blend should cater to both kinds of uses.
>
I did not mean to subsume court administration under any of the proposed
categories. I should have qualified my proposal - the categories are not
an exhaustive list at all. Additional categories can, and should be
added. I was looking for a few categories to sort the already listed
packages into metapackages, and to prioritize this sorting so that I
(and not necessarily others) can ignore certain packages. I wanted a
narrower set of categories[1], so that they are unlikely to overlap too
much with future additions, and also to allow me to drop the categories
that intersect least with these narrower cateogries, and court
administration is one. It will now be added back in, because you do not
want to ignore it.
> - I totally agree with you in that the server/desktop categorization
> might not be very useful for a law office.
I thought of some qualifications to this afterwards. I think the
categories are not going to map 1-1 into metapackages. For each
category, there would be at least two metapackages, one for servers, and
one for desktop/client machines. I haven't digested the whole blends
idea, but I see no reason why metapackages should not have large
overlaps. The metapackages are "weighless", so to speak, they are just
declaring dependencies between packages (+other things), to ease
selection/installation. So if it makes sense to distinguish between
laywers/paralegals/support with regard to say
Loggin/Tracking/Calendaring, then there would be 4 metapackages for that
category (naming syntax may not be correct)
LoggingTrackingCalendaring_server
LoggingTrackingCalendaring_lawyer
LoggingTrackingCalendaring_paralegal
LoggingTrackingCalendaring_support
Each of these metapackages may depend more or less on the same debian
packages, but their configurations will not be the same, but
co-ordinated so as to serve that category of function for the entire law
practice. I have a sneaky feeling that this may be what "roles" are
about, but I haven't read it yet :b
Another thought is that we may not want to lock ourselves into this
server/client paradigm, which seems so obvious. It may not be.[2]
>
> - I would like to propose a sub-category for "evidence management"? Or
> is it within document processing (I personally would think of both as
> separate categories)?
> (Not that there is much soft around for this item that I know of -at
> least FOSS-, but I'm sure it's an area where the need will arise if it
> isn't there yet).
Would you say "evidence management" is more important for what we in the
US call "criminal law"? In any case, it got dropped mainly because I was
thinking "civil law", and did not want to deal with it. So it will be
added back to the proposal.
>
> - Your objections regarding the "legal research" category are quite
> valid, but I think that law offices might well try to centralize local
> court decisions, so I would consider making a sub-category around the
> idea of "precedents collection", since it seems to me that regardless of
> the legal system you are working with, there will always be a need for
> managing the enormous amount of information on legal precedents (roman
> systems do also rely quite a lot on precedents, although they do might
> not have the binding force they have in common law systems). In some
> places, specialized legal information providers are quite expensive and
> unaffordable to small offices in an updateable form, so they might want
> to manage their own in-house collection.
I think this is an enormous problem, and should be in a separate
debian-search project, especially if that search giant were to free all
that search software running on their Gnu/Linux systems. But maybe we'll
be content with just the APIs.
I think "legal research" is a category for lawyers because that is what
lawyers do, but not one for the project of debian-lex, because I believe
we will not see software packages that can do "legal research". I hope
not, I do not want to have robot lawyers. The human ones are scary
enough. There are and will be software that can do very sophisticated
search, restructure data to aid search, but all of it will be totally
generic. Using it for legal research will not be different from using it
for other kinds of research. As for how and who will provide the actual
legal data, that is another huge problem I'll put off for later
discussion.
[1] Actually, "Case Management" covers the whole shebang of what
distinguishes a law practice from ordinary business. I break out the
other categories because many packages address only some aspects. So
"Case Management" overlaps with every other category, and is meant for
packages that do try to address the whole shebang.
[2] I just attended the "Law of the Commons" seminar yesterday, at which
Eben Moglen(http://en.wikipedia.org/wiki/Eben_Moglen) spoke. It was an
amazing lecture, and I hope to youtube it ASAP. I spoke with Eben about
how he runs his law office. He had many provocative ideas, one being
don't presume client/server without thinking about it.
Reply to: