What to ask ourselves this year?

[Daniel Stenberg]

Hi friends,

There's soon time to run our annual survey to see what protocols we're using,
what platforms people use curl on the most and of course what features people
are missing the most.

I'm curious to here from you if there's anything in particular you think we
should ask users about this time. This is the one time in the year we have a
chance to sum up some feedback and comments on our general direction. How
we've fared this far and something about what we should emphasize on going
forward.

Last year we unfortunately only got 176 answers and I really hope we can
increase thay number a bit. A significant point is to keep asking the same
questions over the years so that we can detect trends and changes, but we can
still add good topics and remove bad.

The full 2016 user survey analysis can be found here:

https://daniel.haxx.se/media/curl%20user%20poll%202016%20analysis.pdf

[Daniel Stenberg]

- Would you join the next curl meatup - really!

Ah, yes!

- What's your lowerst and highest amount of payment which you would
spent to join the next curl meatup?

I understand what you're asking but I doubt the answers to such a question
will be very useful for planning the next curlup. Travel, lodging, food and
more are going to vary a lot depending on where you come from and what level
of comfort you assume etc.

I think I rather stick to a simple question in the generic survey now ("Will
you consider attending the next curl meeting?" or something like that) and
then do a specific more meeting-related survey later this year - assuming
we're aiming for another spring curlup in 2018 (and I personally would
certainly like that).

[Daniel Stenberg]

Post by Daniel Stenberg
There's soon time to run our annual survey to see what protocols we're
using, what platforms people use curl on the most and of course what
features people are missing the most.

I would like to know how many discussions or contributions we risk missing out
on or risk never see today by insisting on keeping project discussions/support
on the mailing lists and not in github issues or other "web forums". I
occasionally get told that mailing lists are "old technology" and user
hostile.

But I'm having a hard time to phrase that question in a proper way.

Two obvious, but still quite different, ways to ask:

A) Should we allow discussions in github issues (and not only bugs) ?

B) Have you ever decided NOT to write to the project with an idea or a
topic because of the need to use a mailing list for that?

The problem with (A) is of course that I still wouldn't want to mix
discussions and bugs in the same tracker, so we would still need to steer
people to the right place. (Presumably a separate repo within the curl org for
that specific purpose.) And I really can't ask about specifics like that...

The problem with (B) is that even if you'd say YES doesn't necessarily mean
that the user would've submitted said idea/topic any other way either. Also,
it feels like a question lots of people can answer YES to, but maybe it is
good to have a small bar so that people think twice before submitting?

Ideas?

[Jeremy Nicoll via curl-users]

Post by Daniel Stenberg
B) Have you ever decided NOT to write to the project with an idea or a
topic because of the need to use a mailing list for that?

No, not for this or any other project. If I'm sufficiently keen on an
idea to want
to pursue it, I'll use whatever mechansim is available.

I'm a dinosaur and I like mailing lists. But if a mailing list for a
product is full
mainly of non-technical users' Q&A, often I'd email the maintainer
directly, so
that people with no interest in how something works internally needn't
be forced
to get copies of a 'boring' discussion.

Then again, I'm the sort of person who susbcribes to a mail list for a
product I use
rarely, or in some cases have never used but think I might want to use
at some point
in the future, just so that I can absorb knowledge of how other people
use it without
having to think too much.

Maybe the forums etc appeal to people who only expect to want to ask you
one
question? They don't care about other questions... Or - not using
desktop or
laptop computers - they'd much rather just point their browser at a
pre-existing
forum, ask their one question, and then go away? Those people probably
balk at
having to register on a forum, too.

How much do you care about people who are not willing to make an effort?

[Daniel Stenberg]

Post by Jeremy Nicoll via curl-users
How much do you care about people who are not willing to make an effort?

Well, I don't really see it as a binary thing.

Some people provide brilliant feedback and help. We want that. We want the
project accessible and friendly to newbies.

Is the bar we have today at a suitable level so that we don't miss out on
help or would we as a project benefit from lowering the bar? If so, what does
it mean to lower the bar.

We still need to have the communication channels work for all regulars and
existing developers who are already part of this community. We cannot change
the conditions too much to cater for newcomers so that we risk losing
old-timers.

[Alex Bligh via curl-users]

Post by Daniel Stenberg
A) Should we allow discussions in github issues (and not only bugs) ?
B) Have you ever decided NOT to write to the project with an idea or a
topic because of the need to use a mailing list for that?
The problem with (A) is of course that I still wouldn't want to mix discussions and bugs in the same tracker, so we would still need to steer people to the right place. (Presumably a separate repo within the curl org for that specific purpose.) And I really can't ask about specifics like that...
The problem with (B) is that even if you'd say YES doesn't necessarily mean that the user would've submitted said idea/topic any other way either. Also, it feels like a question lots of people can answer YES to, but maybe it is good to have a small bar so that people think twice before submitting?
Ideas?

I think those as presented have other failings too:

A) sounds a bit like 'would you like to free the citizens from the evil tyranny that prevents them accessing the free world of Github?'

B) is a pretty high bar.

One could still prefer one over the other (full disclosure - I like mailing lists for things like this)


How about something more neutral like:

C) We handle discussions about bugs in the Github issue tracker. For issues other than bugs, we currently use the mailing list. Which would be your preference for conversations about issues other than bugs in the future:
i) continue using the mailing list
ii) use Github to track the discussion (perhaps segregated somehow from bugs)
iii) other
iv) don't care
--
Alex Bligh





-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Eti

[Daniel Stenberg]

Post by Alex Bligh via curl-users
C) We handle discussions about bugs in the Github issue tracker. For issues
other than bugs, we currently use the mailing list. Which would be your

Awesome, that's just so much better phrased than my two alternatives. Thanks!

[David Niklas]

On Wed, 3 May 2017 15:17:08 +0200 (CEST)

Post by Daniel Stenberg
Hi friends,
There's soon time to run our annual survey to see what protocols we're
using, what platforms people use curl on the most and of course what
features people are missing the most.
I'm curious to here from you if there's anything in particular you
think we should ask users about this time. This is the one time in the
year we have a chance to sum up some feedback and comments on our
general direction. How we've fared this far and something about what we
should emphasize on going forward.
Last year we unfortunately only got 176 answers and I really hope we
can increase thay number a bit. A significant point is to keep asking
the same questions over the years so that we can detect trends and
changes, but we can still add good topics and remove bad.
https://daniel.haxx.se/media/curl%20user%20poll%202016%20analysis.pdf

My problem with online surveys is that they open and close so fast and
unless you are looking to fill one in, you often times don't know that it
even started and ended until someone publishes the results.
This happens to me with the linuxquestions and opensuse surveys almost
every year.

Thanks,
David

-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mai

[Daniel Stenberg]

Post by David Niklas
My problem with online surveys is that they open and close so fast and
unless you are looking to fill one in, you often times don't know that it
even started and ended until someone publishes the results. This happens to
me with the linuxquestions and opensuse surveys almost every year.

My plan is two have this one open for 14 days, two full weeks (starting some
time around mid/end of May). I figure that should be enough time to reach out.
What do you consider "so fast" ? (Previous surveys have been open for 10 days
I believe.)

The stats from previous years have shown that we get very few extra input
after the first few days after reaching out. The problem is rather to really
reach out and find the users and make them interested enough to actually spend
a little of their precious time on us. I think extending the time is valuable
if we think that extra time can be used to reach out to more
people/communities.