Yes.
Hi -- nice to meet you.
Is there something you wish to discuss?
A couple questions:
(1) When I sent my first email, I received a private reply that said this:
Yes.
>
> ... a reply-to that doesn't point to the list would have been nice...
to which I replied:
I wish I knew what you meant!
This is what I was sent when I joined the list:
"Welcome to the tosw(a)lists.fedorahosted.org mailing list!
To post to this list, send your email to:
tosw(a)lists.fedorahosted.org <---- this is where I sent my email
General information about the mailing list is at:
https://lists.fedorahosted.org/mailman/listinfo/tosw
If you ever want to unsubscribe or change your options <snip>
I haven't received a response, but I don't want to screw up again in the future,
so what did I do wrong? I sent my email to tosw@lists.fedorahosted.org... Was there
something else I was supposed to set in my email (and how was I supposed to know that?)
(2) On "The Open Source Way": I am trying to suss out the intersection between
"collaboration" and The Open Source Way. In a function that doesn't involve
development (like Facilities or HR, for instance), how does working "Open
Source" _differ_ from collaborating?
* Does everyone have to agree on a plan to work Open Source? (consensus version)
* Can problems or parts of problems have Owners, with the acknowledgement that owners need
to get input from other people, but that the final decision rests with them? (This is
antithetical to the consensus version
* I understand the "glass houses" (and think it's critical to expose your
process). Is there a guideline for how "formed" something needs to be before
it's released into the wild for commentary? The argument could be made that if
something is not well-thought out enough, then releasing a half-baked idea could just
cause more confusion -- how do you balance this?
* Programming projects (to some degree) have a built-in "sanity check," in that
Things Will Break if people start messing about with things they oughtn't to, etc.
IMHO, this gives programmers more freedom to see something and fix it. In the
non-programming world, there's no built-in QE function, so people are far more
cautious (it seems) about taking on things that are in grey areas or new areas, for fear
of breaking something (process or relationship). How do you counter that so you can get
to the "release early, release often" model.
These may be questions that are answered online or in literature, but I've had
difficulty finding answers that are about *working* Open Source, as opposed to developing
Open Source. I need some ideas about what Open Source looks like when it's not in an
engineering org.
Thanks for any help on (1) or (2).
Best,
Gina
Gina Likins
8W337, Red Hat Tower
100 E. Davies St.
Raleigh, NC 27601
glikins(a)redhat.com
(919)890-8322 or internally 48322