[OpenISO] OpenISO.org Core Guidelines

Thomas Bader thomasb at trash.net
Fri Sep 21 23:30:20 CEST 2007


* Norbert Bollow <nb at bollow.ch> [070921 10:40]:
> I'd suggest to use "should" / "should not" for procedural
> requirements which, if not satisfied, will result in the concerned
> action or specification being considered noncompliant with
> OpenISO.org requirements.
> 
> I'd further suggest to use "must" / "must not" for requirements
> which, if not satisfied, will result in the concerned action or
> specification being considered noncompliant with OpenISO.org's
> interpretation of international law and/or other widely-recognized
> principles of law.
> 
> My suggestion for "can" vs "may" is as follows: Use "can" / "cannot"
> to describe ability or possibility independently of whether the
> concerned possibility is required, allowed or forbidden; use "may"
> to described something which is allowed but not required.

I agree to this definitions.

> How about the following?
> 
>   Maturity requirements include that a complete non-copyleft or
>   weak-copyleft free software implementation should exist, and
>   that the spec has been reviewed for cross-cultural applicability
>   and with regard to its impact on people with disabilities.

Yes, this sounds fine to me.

Another tought on that: Couldn't it be possible that we
create a "chicken-egg" problem? Let's imagine OpenISO will
be very very very popular in some years - a recommendation
of a standard might speed up the development of a free
implementation then, while a missing recommendation might
slow down the efforts to finish an implementation.

> > I think that the "disclose employer" sentences in this draft
> > are a bit indistinct. Would you require this in any case
> > or only in cases where someone has an employeer that has
> > something to do with the discussed standards?
> 
> What would you propose?

Well, I'm not sure about this yet.

In some industries (e.g. in IT-Security) it's quite common
to have non-disclosure agreements that prohibit disclosing
clients. Besides that, some methodologies that are well
known in this business (such as the OSSTMM) consider it
unethical to disclose clients. Should one who works under
such circumstances not be allowed to join OpenISO working
groups?

This first example was about people who are self-employed. I
also see some problems with regular employees: Suppose we
discuss about a standard made by vendor X. A person joins
the working group and discloses company Y as being her
employer. How do we know if vendor X might not be a client
of company Y? In such a case, company Y might also have an
interest to have their clients standard being recommend, but
we do not recognize that since the relation between company
X and Y is not evident.

I think, the need to disclose employers is a bit unfair: In
my opinion, we except all those from the working groups that
are not allowed to disclose their employer while we open up
some blackholes in case relations between companies are not
evident.

A third concern would be about people that are not speaking
for their employer. Only because a person works for employer
X does not mean that the person speaks for her employer in
her spare time. With an adaption of a "disclose employer"
article we also communicate to the outside world that we
assume that people have sold their souls to their employer
in _any_ case.

Actually, I'm not really sure yet what my proposal could be.
Therefore I'm just able to raise my concerns and hope we can
discuss about them :)

Regards, Thomas.


More information about the Discuss mailing list