From: Thien-Thi Nguyen <ttn@giblet.glug.org>
Cc: guile-devel@gnu.org
Subject: Re: kudos and observation
Date: Wed, 03 Apr 2002 13:34:33 -0800 [thread overview]
Message-ID: <E16ssOn-0003S5-00@giblet> (raw)
In-Reply-To: <15531.248.122662.447359@winona.neilvandyke.org> (nwv@neilvandyke.org)
From: "Neil W. Van Dyke" <nwv@neilvandyke.org>
Date: Wed, 3 Apr 2002 08:17:44 -0500
When making decisions in a group like this, I think people in
general tend to negotiate the proportions subtly for each
situation. More a collective art than a science.
this kind of constant negotiation is difficult to scale, and some
(actually most) people really aren't comfortable w/ negotiation
at all. in the job context where there are processes already in
place to alleviate these issues, negotiation is best done up
front (at interview time).
is guile maintenance (or more generally any free software project
collaboration) a job? that's hard to say. i know that i put in
lots of hours for some tenuous future benefit (being able to
compile THUD modules), which is kind of like a job...
There's few enough core Guile developers that there should be
little need for edicts. The team is small enough for everyone
to be heard in a discussion. Also, in those cases in which
consensus on an issue is not quickly reached based on the
merits of the issue alone, everyone on the team recognizes
that compromise is sometimes necessary to move forward and to
maintain a cooperative tone.
the TODO list is pretty daunting for a small team, and i imagine
doubly daunting for a large team that's unorganized. personally,
i'm trying to encourage documentation of our current processes so
that we attain the minimal self-awareness necessary to be able to
teach that process to the new blood (and improve the process in
the process!).
(Just an opinion. I really hesitated to say anything at all,
since I'm not a core Guile developer myself. But I hated to
see unresolved team dynamics glitches that probably require
only the slightest prodding to fix.)
well the ancients say a good doctor cures your illness and the
best doctor prevents illness in the first place, so a little
fixing w/ a little forward-fixing seems "indicated" here.
somewhat related, you sent `when' and `unless' and have
contributed other useful patches. do you have any interest in
guile repo write privs? (this is not an offer per se, just a
feeler.)
thi
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2002-04-03 21:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-30 7:25 kudos and observation Neil W. Van Dyke
2002-04-03 9:41 ` Thien-Thi Nguyen
2002-04-03 13:17 ` Neil W. Van Dyke
2002-04-03 21:34 ` Thien-Thi Nguyen [this message]
2002-04-04 5:18 ` Neil W. Van Dyke
2002-04-04 22:04 ` Thien-Thi Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E16ssOn-0003S5-00@giblet \
--to=ttn@giblet.glug.org \
--cc=guile-devel@gnu.org \
--cc=ttn@glug.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).