[Imc-lwg-general] [docs] constitution refinement proposal /2

[Richard Malter]

*--------my comments:


Quoting toni -- <tony@irational.org>:
summary: 

proposals: 

- term PROJECT to substitute FUNCTIONAL ELEMENT
*------- below i will argue still for FUNCTIONING ELEMENT 
- two types of projects to be recognized (permanent and short) 
*------- i will argue that this is adding detail; maybe put as annotations.
- term CHARTER to substitue CONSITUTION 
*------- agree. with suggestion.
- special case of 'subgroups-with-single-short-projects' 
  to be recognized and included 
*---argue again that this is adding detail; maybe put as annotations.

On Tue, 26 Feb 2002, Richard Malter wrote: 

> and also functional element to 
> "Functioning element". 

currently we define Functional elements: 
"Functional element = any task that furthers the objective of imc-lwg 
and that does not contradict it's constitution." 

however, these words can be misleading. our intital argument, 
if i remember well, for use of word 'functional' because it has to be 
operational - performing desired function, that, we said, reflected 
the notion of 'running code'. 

but let's look at the example of an public event. 
it has start and end. it is certanly not 'functioning' after it has 
finished. there are many other examples like that. for example, features 
subgroup can set itself a task to report on some event. it again, ends at 
some point and is not 'functioning' any more. 

*------i follow; but const. says that:
"6<e> when a working group stops doing implementation longer than
the agreed period (see 6b), they cease to exist as a group."

so is this not covered already?


word that ben used in guideliness that he compiled instead is 'project'. 
simplicity rules. 

*----agree about simplicity; but "project" is not accurate (enough). we tried 
to describe the _quality/attributes_ of the identified element not just the 
fact that it exists. so don't think "project" works. As said also, i think as 
long as we have user interface(s) that are everyday language, our source 
document can be 'technical' in that it aims for high level of accuracy; and 
that is not bad; remember also that we did many dry runs - and found that we 
had to be this accurate not to 'slip' into something else; i know its sounds a 
bit too rigid/discriminatory, but remember that we are identifying one pattern 
in a large complex system of many observable patterns, like a camera 
photographs a landscape, so inevitable the 'snapshot' will appear static 
somewhat.

the only difference between projects like above 
mentioned public event or reporting, and those that are on-going like 
documentation, maintenance of technical resources is in lenght. 

*--------but again covered by measurable terms, no?:
 "5<b> The new subgroup has to propose the goals of
each functional element it wants to create in measurable terms, 
>>>the period it will continue<<<<, and the period of notice if it stops."

thinking of term 'project' instead of 'functional elemnet' i come to 
conclusion that there are two types of projects: 
permanent (documentation,tech) and short (event,report). 

i think this describes the actuall situation much better then 'functional 
element' does, 

*------ the way i follow you is that you are adding detail(s) to a model. which 
isn't bad of course, but a) justification for more detail than already have? 
and b) where draw the line in detail? Answers are by next question: Why did we 
draw the line where we did? answer=i think becuase we thought that we had 
arrived at a scheme that generally included all the various elements: time, 
commitment, measurability, interdependence, method of decision-making etc, and 
that the details could be added on ad hoc. But we could always have annotations 
and below the main doc. list more details, that way also we give the reader 
option to read more or less detail which is v. important consideration. 

and the widespread use of term makes it more appealing. 

important is that we don't loose the grip on what we want to say by the 
common use of the term. i don't think that's the case with term 'project'. 
quite contrary. why we didn't think of something as simple as this is 
different matter. 

*-----see comments up.

so, i proposed use of term "PROJECT" instead of "functional element". 

------- first diversity of perspective in lwg ;)

as well, i propose slight change/extention of the definition: 

"PROJECT = any task, or set of tasks that furthers the objective of 
imc-lwg and that does not contradict it's constitution. >>>We recognize two 
kinds of projects: permanent and short. Permanent are those that do not 
have an end point, and are ussualy at the core of the working group, 
while short have defined end point [examples]" <<<<

*--------- think as annotation, and then below main body of const.

another proposal is use of term CHARTER instead of CONSTITUTION, 
for one simple reason: apart from the fact that these two terms 
cross-reference each other, term 'constitution' suggests it's common use 
in the context of  government - which is quite different to what we 
are trying to do. so let's get rid of the negative conotations that 
this terms imposes on us. 

*--------- agree. but i kind of like that we _name_ it "the constitution" ;) 
even if we describe it always as the charter. just a suggestion.

> >Propose: change use of term 'subgroup' to 'component group' (that we touched 
> on). 

'sub' is accurate (subgroup is within larger group, in our case because 
it accepts the charter), 
but suggest certain structure with it's strong conotations of 
commons use (which isn't positive at all). 

*-----yes, if think about it, it is something within/under something - 
definitely belongs to hierarchy/non hierarchy paradigm. so i argue that we 
cannot use " subgroup", becuase we "contradict it's [lwg] constitution" - ie 
the const. contradicts the const.! very strong argument, no? Nick (my friend) 
pointed this out too.

'component' sounds too technical to me. offputing :( 

*-------- agree.

i would prefer keeping sub for now and thiking further about it. 

*------- well, why not just "working group". simple, no? no confusion either.

as well, 'functional element' and 'subgroup' can easily be confused. 
[]. 

*------ don't think this is so strong argument, can give example how?

let's not forget that we are trying to _recognize_ patterns and the model that 
they belong to, not to build patterns ourselves. 

*--------true.

[]

think i addressed rest above. please say if i missed/skimmed over something.

Richard