On Sun, Sep 26, 2010 at 8:46 AM, erwin blom <erw...
> it's really difficult to play a role in an open source project. And because of
> that too often projects remain too techy in my opinion.
This is actually a cycle, fueled by people thinking that code is the
only real contribution. It's a lie that directly leads to people
complaining that open source projects have bad visual design and even
worse documentation, among other things.
> 1) How can non-developers play a bigger role in technical open source
> projects that in the end are meant to work for everyone?
* If you can organize your thoughts well, help write/edit
documentation: Many developers don't like doing this, and when they do
it often ends up being written for other developers rather than users.
It isn't sexy work, but it's more important than most people ever say.
* If you're design-oriented, help with that: They're called developers
because they're not (usually) designers.
* File bugs, feature requests: Many people, when confronted with
software that's not working properly or doesn't do what they need,
will complain in the abstract rather than do something about it, which
helps no one. "Do something about it" doesn't have to go as far as
producing the code; at least point out the problem, as clearly as
possible. As long as you make your case, other people will take care
of the parts you can't handle.
* Money/wishlist purchases/canned goods(beer): Even when it's not a
lot, it still says, "Thanks."
> be very important to select and organise the best answers to a
> question ans embed them in a blogpost. For example Keepstream does
This is actually a really good idea(plus I wasn't aware of
Keepstream), though right now the focus is on getting the core
application itself working for a 1.0 release.
But this general concept is not out of order, cf. http://github.com/ginatrapani/ThinkUp/issues#issue/152
You might want
to open a new issue or comment on that one, proposing a more
generalized way to embed TU info into pages, since that's obviously
tied to WordPress.
> But asking for them feels
> like being a spoiled internet-user that wants all ;-)
Ultimately, you're the person being served. Otherwise, you end up with
a bunch of engineers making something that's only going to be
interesting to other engineers. Your end of the deal is to /not/ be
spoiled. There's nothing at all wrong with asking for a feature or
pointing out a bug. Just do it respectfully and helpfully. If you make
a feature request, explain /why/ it's a useful thing. If you think
it's obvious, explain anyway; you'll get points for showing you
thought it through. If you're challenged on it, then defend your idea,
within reason. Being asked why you'd want to do that means "convince
me" not "go away."
And sometimes the answer's just going to be no; if so, don't throw a
tantrum. (Yes, that happens, though I haven't seen it here.)