real world problems vs. abstract problems - distinctions? policy?

[MON KEY]

One often encounters certain like or similar terms/phrases w/re Emacs
bugs, errors, (mis)interpretations of functionality etc. which hinge
on party-A's dismissal of party-B's understanding/interpretation of a
problem as being somehow not of the "real world". Presumably the
counter to a "real world problem" is a problem which occurs as an
"abstract problem".

I'm interested to learn how with regards Emacs and Emacs development
this distinction between "real world problems" and "abstract problem"
is understood by the emacs-devels and to inquire for some informal
public policy which exposes what the emacs-devels collectively
understand these distinctions to entail.

As an exercise I drafted the following as an attempt to clarify how a
problem moves through the collective emacs-devel community.

----

An 'abstract problem' is one in the set of problem types which are not
immediately recognizable as constituting a 'real world problem'.

These include (but are not limited to) those types of problems termed:
'dismissible', 'un-producable', 'un-verifiable', 'unprofitably
addressable', 'addressably unprofitable', 'bikeshedably prolongable',
'prolongably bikeshedabe', 'license terms puntable', 'user un-visble',
'un-fixable', 'breakably fixable', etc.

The extent, temporal specificity, and locality (whether purely abstract
or formally syntactic), in which the set of 'real world problem'
problem types is said to contain a particular 'abstract problem' need
not be formally specified with the informal caveat that in order for
an 'abstract problem' problem type to transition into the set of 'real
world problem' types it may do so iff it is enclosed by the scope of
those problematic types which are known to be either 'addressably
profitable' or 'profitably addressable'. When a 'real world problem'
is known to be either 'addressably profitable' or 'profitably
addressable' it can be said to have 'surfaced'. This is an important
distinction, an un-surfaced problem is not unlike the tree that falls
in the forest with no one around, it may make a noise but if no one is
their to hear it...

An exception to the above informal caveat is a more formal
(semi-formal?) constraint which guards against the informal
inclusionary conditional that an 'abstract problem' which is either
'addressably profitable' or 'profitably addressable' may become a
'real world' and surfaced problem type. This guard is placed around a
certain set (or sometimes subsets) of 'abstract problem' types which
intersect with one or more members of the set of problem types termed
'deficient implementation details'.

A 'deficient implementation detail' type is a problem type
characterized by one or more claims or assertions of problems arising
from a 'deficient implementation'. The veracity of such claims or
assertions being independent of whether the problem type's details,
implementation, and/or deficiency(ies) are existent and obvious, nor
whether any one or more of these be so for any one or more person(s)
party(ies), groups, factions etc.

A 'deficient implementation detail' problem type should not receive
consideration for inclusion among the set of other 'real world'
problem types until the addressable details of a particular 'defective
implementation detail' problem type are said to have surfaced.

Surfacing a 'deficient implementation detail' problem type involves
the following stages:

- an enumeration of the deficiency details is made indicating:
  -- observability, verifiability, reproducibility;
- a veracity of claim must be acknowledged
- a determination/disclosure of the problem
  -- 'addressable profitability' or 'profitable addressabilty'

For acknowledgment of a 'deficient implementation details' type
problem to occur an enumeration of the putative problem's
'defenciency details' must exist. Such an enumeration is said to
constitute the details of a 'deficient implementation'.

Enumeration of 'deficiency details' requires verifiability of one
or more deficiency detail.  A particular deficiency detail is said
to be verifiable if during normal execution at the user level the
detail of an implementation deficiency can be observed. A deficiency
detail is said to be observable at the user level iff all code
executed in the current user environment is free of both user written
code execution at the user level and/or execution of user-level code
changes to non user-level code. If it can be said that an observable
deficiency detail of an implementation deficiency is verifiable, then
the detail is said to be reproducible.  When an arbitrarily sufficient
number or amount of such deficiency details is enumerated the
cumulative effect is that a 'deficient implementation detail' can be
said to be reproducible.

Note however that reproducibility (whether cumulative or piece-wise)
of the details regarding a claim to a 'deficient implementation' does
not verify that the claim is correct nor that there is in fact a
problem only that the possibility of one may exist.

When a consensus of like minded overseers (this being comprised of
individuals with the requisite suitable experience commiserate for
inclusion among such a a peerage of the like minded) that a claim of
'deficient implementation detail' has veracity will an
acknowledgment of such be made known. Presumably at the collective
discretion of the peerage will dictate what is proper.  However, there
is no mandate that such an acknowledgment occur and any such
acknowledgment need not be shared outside the enclave of the peerage.

When the veracity of a claim of 'deficient implementation detail' is
made known or otherwise acknowledged, the peerage may at their
discretion, choose also to accompany the acknowledgment with an
informal statement, hint, or indication as to whether the problem type
was determined to be 'addressably profitible' or 'profitably
addressable' and possibly the extent to which this determination might
change according to unforeseen or unacknowledged mitigating
circumstance(s).

The above exploration of informal policy and its qualifiers:
"abstract problem", "dismissible", "real world", "obvious",
"deficient" "implementation", "detail", "profitable", "addressable",
"surface", "reproducible", and "user level" are intentionally left
unspecified.


--
/s_P\