1) How can non-developers play a bigger role in technical open source
projects that in the end are meant to work for everyone?
I'm interested in technology, i know what i want, but i'm not a
programmer, i don't write code. I love the concept of open source, but
because that means most of the time writing a code, 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. I don't have a
solution, i respect all the work all you programmers put into a
project like this. But i would love it when endusers or designers
could from the beginning play a bigger part in technical projects like
this.

2) Because it's difficult to play a role, it's difficult to ask for
features.
I'm spending a lot of time trying out new services. For example the
curate-services that are being developed. I see features there i would
like to have in ThinkUp. For example: collecting and archiving is one
thing, but selecting and republishing is another thing. To me it would
be very important to select and organise the best answers to a
question ans embed them in a blogpost. For example Keepstream does
that. Without functions like that, ThinkUp won't be the hit for me i
thought it would without features like this. But asking for them feels
like being a spoiled internet-user that wants all ;-)

In a next life i will be a developer!

Erwin

Actually, I think your opinions are extremely valuable to us.
Engineers like us are good at implementing things and solving hard
problems, but some of us tend to prioritize that over creating
products usable for other people (Google itself sometimes falls prey
to this). I think your opinions are something we should listen
intently to, because chances are, other non-programmers would have
similar complaints to you, and they're things we need to think about
if we want this to be usable to them.

That's not to say we'd necessarily share the same vision of what the
software is meant to be, but all the same, I would personally love to
hear your constructive criticism, frustrations and advice. :)

--Mickey

--
Michael Louis Thaler
Phone: 201-632-1674
Twitter: mithaler

As Mickey said, help the developers adjust the interface so it makes
sense for humans. This is a VERY important part of the project.
Developers are too far in the forest to see the trees. Suggestions
like Su's re: the installer in an earlier thread today are deeply
helpful. Sketching out mockups of how you think something can
look/feel/work more sensibly is a huge contribution to the project.

Asking for new features is totally ok--but if they're complicated
features like curating publishable replies, for example, include
mockups of screens with how you envision it would look so the list can
discuss. It's hard for developers to get requests for complicated
features that represent a big chunk of work without a good idea of how
great it would look or how easy it would be to use. Seeing screenshots
and good mockups would get everyone excited to actually build it.

--
http://ginatrapani.org
http://twitter.com/ginatrapani

Maybe it's off topic. And maybe it's an idea for a future project. But
in my opinion the way the people at Amazon work could mean an open
source project could start less technical than very often is the case.
And could involve a broader group of people.
How do they start a project at Amazon? They call it 'working from the
customer backwards'. So they start with the product. Or version one of
the product and start describing it with the user / customer in mind.

   1. Write the press release. Force yourself to explain in simple
words what it is, what it does etc
   2. Write the FAQ. Which questions do you expect and what are the
answers.
   3. Write the user manual. Explain.

Once you've done that, start building. Something like this could
involve a bigger audience than developers. In that case someone like
myself could in a wiki or newsgroup play a bigger role than now.

But like i said, maybe for a new project. Keep up the good work!

More info: http://www.allthingsdistributed.com/2006/11/working_backwards.html

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.

* 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."

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.

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.)

Link, please? I always donate to projects I use, test and like.

/r