The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: project leader's position on the "deity" team



On Mon, 14 Apr 1997, Bruce Perens wrote:

> I am loath to discourage seven people who are planning to make some progress
> on a serious issue for Debian that has been stagnant for too long. Although
> I think the team could have been convened more gracefully, I am willing to
> believe that they are competent.
> 
> This is a formal request from the project leader to all Debian developers.
> Please provide guidance and assistance where necessary so that the "Deity"
> project succeeds.
> 
> I have from Brian "This is not going to be any kind of closed development".
> That came from my request that Erik Troan be involved, and it should apply
> to Debian developers as well. If you are shut out for no good reason, let me
> hear about it. Otherwise, I expect you to be helping, and not hindering this
> project.
> 
I agree with what Bruce has to say here and have a point of my own to add.
(You doubted that? ;-)
It is my understanding that the "Deity Team" has a "private" mail list to
carry on their deliberations. I completely approve of this list. I think
that it is absolutely necessary that the team be able to "huddle" in a
quiet corner and carry on critical discussion without the "distractions"
of the broader group. My only caution here is that "privacy" not be turned
into "isolation". I the team stays in the huddle until it has a "new
product" and "springs" it on the rest of the developers as an accomplished
solution, I can almost certainly predict problems with the integration of
the new product. To avoid this, I suggest a simple test. The test will
tell the team members when to break the huddle and ask for decission help
from the group at large. During "design spec" discussions you evenutally
come to the following state:

	1. I (the team member) know which way I want this to go and want
           option A.
	2. Option B is one that others want and I can accept.
	3. There are several other options but I don't like them and don't
           think others will either.

If there is only #1 then the team probably needs to inform the larger
group of that fact, and let the group "prove" your assumption. If #1 and
#2 both exist it is definitly time to ask the larger group. Don't hesitate
to discribe additional options even if they do not appear to be useful.
The synergy of the group can produce completely new options from concepts
in "failed" ideas.
The best paraphrase for huddle breaking is: Break early, break often!
Communication by "the team" with "the larger group" will help us all
converge on the same, hopefully exceptional, sollution. Keep the rest of
us appraised on the path and most will follow along. (if only to see the
sites/sights ;-)

Waiting is,

Dwarf
-- 
_-_-_-_-_-_-                                          _-_-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (904) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-