[eDebate] No Justice, No Peace, No Moon
Mon Aug 4 14:09:45 CDT 2008
david glass writes (http://www.ndtceda.com/pipermail/edebate/2008-August/075503.html),
"I've been making
these points about the need for a theoretical framework that could make
distinctions between acts deemed "ethical" or "acceptable" and those deemed
over the line,
nobody... truly, nobody... has offered a framework that
excludes the seeming unacceptable
behavior, but allows the alternative
forms... That seems to be a problem worth pointing out."
well, before propelling ourselves headlong down the slippery slope of dangerous 'slippery
slope'-analogies, it might serve the discussion to return to the round itself.
towson neither called their opponents racist nor 'personalized' the debate. they disagreed
with a decision taken by the opposing team and did so in a professional way using a formal
debate argument. the 2a.c. says, "this isn't a question of their sincerity or their intentions;
this is a question of their methodology" (28m:15s).
to me this puts a sizable fly in your soup, dr. glass -- namely, this round is a poor example
of what happens when theoretical frameworks are abandoned for standard-less lala-debate
for the obvious reason that the towson team presents a fair and reasonable framework with
a clear and consistent anti-racist standard. they asked, how can you strike a black judge in a
predominantly white pool and still claim to be promoting racial inclusiveness?
now i think we can agree that there's lots of better answers to this question than those which
were given by the fort hays team during the round in question. nevertheless, the question is
a legitimate one, regardless of whether you find it persuasive, and you've failed to show how
this necessarily results in slippage.
glass: "a debater could be called out for being
a Red Sox fan"
...and they could easily respond back with 'i'm not a red sox fan', or with 'that's irrelevant'.
an important part of the traditional framework (i think you'd agree) is non-interventionism. this
means that a debater could argue 'vote for us because the sky is blue' along with a hundred
other blips. if dropped, these are supposed to function as round-winning arguments. somehow
this permissiveness hasn't spelled the destruction of the activity. so what's special about reflexive
kritiks? in fact (and here's the fat turn), reflexive kritiks offer debaters a theoretical framework
for propagating the very codes of civility required. [see card in post-script.]
i agree wholeheartedly that the regrettable spectacle was inappropriate and potentially violent. it'd
be a huge mistake, however, to punish students for the sins of their teachers, or to start censoring
in-round content alongside censuring after-round misbehavior. and the notion that trends such as
lax enforcement of topicality causes anarchy like this is as patently ludicrous as the leap from pies
to incendiary devices (http://www.ndtceda.com/pipermail/edebate/2008-August/075495.html).
with all due respect, you're comparing apples to assholes.
Our opponents' briefs are covered under traditional copyright and are
not available on the web. The example of Linux software proves that
Internet access to everyone's work and protection under public licenses
are two indispensable components of distributed networks. Formal
incentives systems, such as ballots, must discourage hoarding and
consistently remind debaters to share, otherwise collaborative projects
will fail. Your ballot sets down the rules of the road.
Jae Yun Moon. Doctoral candidate in Information Systems at New York
University. & Lee Sproull. Stern School Professor of Business at
NYU. 2000. ('Essence of Distributed Work: The Case of the Linux
Kernel'. First Monday. Volume 5; Number 11. http://www.firstmonday.org/issues/issue5_11/moon/index.html.)
Others have written about lessons from Linux for commercial software
development projects (e.g., Raymond, 1999). Here we consider how
factors important in the Linux case might apply more generally to
distributed work in and across organizations (also see Markus, Manville
and Agres, 2000). It might seem odd to derive lessons for formal
organizations from a self-organizing volunteer activity. After all, the
employment contract should ensure that people will fulfill their role
obligations and act in the best interest of the organization. Yet,
particularly in distributed work, employees must go beyond the letter
of their job description to exhibit qualities found in the Linux
developers: initiative, persistence, activism. We suggest that the
enabling conditions for Linux (the Internet and open source) usefully
support these conditions. We then consider how factors emphasized in
each of the three versions of the Linux story (great man and task
structure, incentives for contributors, and communities of practice)
can facilitate organizational distributed work.
Clearly easy access to the Internet or its equivalent is a necessary
precondition for the kind of distributed work represented by Linux.
Developers used the Internet both for easy access to work products (to
upload and download files) and for easy communication with other
developers (to ask and answer questions, have discussions, and share
community lore). Both capabilities are surely important. And they are
simple. It is noteworthy that, despite the technical prowess of Linux
developers, they relied upon only the simplest and oldest of Internet
tools: file transfer, e-mail distribution lists, and Usenet discussion
groups. Even with today's wider variety of more sophisticated Web-based
tools, Linux developers continue to rely on these tools for
coordinating their efforts. These tools are simple; they are available
worldwide; they are reliable.
The organizational equivalent of copyleft is a second precondition for
the kind of distributed work represented by Linux. Both the formal and
informal reward and incentive systems must reward sharing and
discourage hoarding (See Constant, Kiesler and Sproull, 1996, and
Orlikowski, 1992, for discussions of incentives for information sharing
in organizations). Moreover work products should be transparently
accessible so that anyone can use and build upon good features and
anyone can find and fix problems. We do not underestimate the
difficulty of creating the equivalent of copyleft for organizational
work products. Failing to do so, however, can hobble distributed work.
Finally, Linux developers were members of and supported by vigorous
electronic communities of practice. Creating and sustaining such
communities can importantly contribute to distributed work. Electronic
communities require both (simple) computer tools and social tools. We
discussed computer tools under enabling conditions, above. The social
tools include differentiated roles and norms. It is not enough to
enable electronic communication among people working on a distributed
project. In a project of any size people must understand and take on
differentiated electronic roles. These roles, with their corresponding
obligations and responsibilities, should be explicitly designated and
understood by all. Indeed, one category of community norms is the
expectations associated with role behaviors. More generally, norms are
the "rules of the road" for the particular electronic community.
Because distributed projects cannot rely upon the tacit reinforcements
that occur in face-to-face communications, persistent explicit
reminders of norms are necessary in the electronic context (See Sproull
and Patterson, 2000 for more on this topic).
Get more from your digital life. Find out how.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mailman