You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Jan Lehnardt <ja...@apache.org> on 2016/01/14 12:45:10 UTC
Getting people to test CouchDB 2.0 alpha releases
Dear marketing team (cc dev@),
over the holiday break I made first build for CouchDB 2.0 available and have written up a document on how to get started with testing it at https://docs.google.com/document/d/1BtndYr-0KDQTqBSLVdJoR_8C5ObYjT1RBo_Qyh5ykdQ/edit# and I’ve also used Twitter to spread the word, and we’ve had this in last week’s weekly news.
But we’re not seeing a lot of people giving these builds a spin. I’m not 100% on what to expect, but I would have expected a *little* more buzz around this :)
Can you help brainstorm a few ideas on how to get this in front of more people, and how to get them to try out CouchDB 2.0 alpha?
These things are circling in my back of the head:
- Maybe the doc is too dense and not fun enough, or to badly written, please suggest any edits that you may think help (or scrap it and make an alternative, if you think it can’t be saved :)
- Some people reply with “do you know when it is out of alpha and in beta?”, because they think alpha is to early to get into the game. I usually reply that we go beta as soon as they reported all the issues they found, but it didn’t help yet ;) — How do we convince those who *would* help, to help earlier?
- Can we simplify the getting started experience?
- Should we host a public cluster somewhere, that people can play with?
- How do we get client library authors to test with CouchDB 2.0? (can we come up with a .travis.yml file that they can maybe use in a 2.0 branch of their tree (maybe PouchDB has something there already))
- Can we simplify the procedure of how to report issues?
- Can we put a feedback form into Fauxton? (maybe an embedded Google Form is enough?)
- Can we put a web-chat pane into Fauxton, so people get a quick way to get into our IRC channel?
- Can we track installations somehow, e.g. along the lines of “send anonymous data to the developers” where we can track the operating system / cluster config / maybe data sizes etc? (all opt-in of course).
- Can we make this a mmopg? Maybe we draw up a huge matrix of test configurations that we’d like to see tested, and people get points for filling it out, and we can crown the top-alpha-tester-champion or something?
- Something similar for qualified bug reports in JIRA?
- Are there publications we should be talking to?
- INSERT YOUR IDEA HERE
* * *
For all ideas we should consider the effort to set them up and maintain continuously.
Let’s do this! :)
Best
Jan
--
Re: Getting people to test CouchDB 2.0 alpha releases
Posted by "Eli Stevens (Gmail)" <wi...@gmail.com>.
Not sure if I should keep marketing@ on the CC list; erred on the side
of inclusion.
Docker didn't exist when we started our project, and we've not felt
the need to start using it, so it's a hurdle (a small one, but enough
that we've not bothered to alter our build scripts to include the new
dependency and startup steps).
Speaking only for myself, having something as close to a drop-in
replacement for the Ubuntu 12.04 LTS packages of 1.6.1 would be what
we need to easily test CouchDB 2.0.
So to that end, my company is getting a contract set up to have those
produced, with the intention of having the build scripts, etc. donated
back to the project and the binaries freely available on the
couchdb-stable PPA. That internal initiative was prompted by this
email thread (since I realized that not having what we needed is a
problem that could be solved with dollars), so it's a good thing you
asked. ;)
Timelines aren't 100% clear yet, but at the very least announcements
will be made when various artifacts are available. Might be a couple
of months, not sure.
Cheers,
Eli
On Thu, Jan 14, 2016 at 3:45 AM, Jan Lehnardt <ja...@apache.org> wrote:
> Dear marketing team (cc dev@),
>
> over the holiday break I made first build for CouchDB 2.0 available and have written up a document on how to get started with testing it at https://docs.google.com/document/d/1BtndYr-0KDQTqBSLVdJoR_8C5ObYjT1RBo_Qyh5ykdQ/edit# and I’ve also used Twitter to spread the word, and we’ve had this in last week’s weekly news.
>
> But we’re not seeing a lot of people giving these builds a spin. I’m not 100% on what to expect, but I would have expected a *little* more buzz around this :)
>
> Can you help brainstorm a few ideas on how to get this in front of more people, and how to get them to try out CouchDB 2.0 alpha?
>
> These things are circling in my back of the head:
>
> - Maybe the doc is too dense and not fun enough, or to badly written, please suggest any edits that you may think help (or scrap it and make an alternative, if you think it can’t be saved :)
>
> - Some people reply with “do you know when it is out of alpha and in beta?”, because they think alpha is to early to get into the game. I usually reply that we go beta as soon as they reported all the issues they found, but it didn’t help yet ;) — How do we convince those who *would* help, to help earlier?
>
> - Can we simplify the getting started experience?
>
> - Should we host a public cluster somewhere, that people can play with?
>
> - How do we get client library authors to test with CouchDB 2.0? (can we come up with a .travis.yml file that they can maybe use in a 2.0 branch of their tree (maybe PouchDB has something there already))
>
> - Can we simplify the procedure of how to report issues?
>
> - Can we put a feedback form into Fauxton? (maybe an embedded Google Form is enough?)
>
> - Can we put a web-chat pane into Fauxton, so people get a quick way to get into our IRC channel?
>
> - Can we track installations somehow, e.g. along the lines of “send anonymous data to the developers” where we can track the operating system / cluster config / maybe data sizes etc? (all opt-in of course).
>
> - Can we make this a mmopg? Maybe we draw up a huge matrix of test configurations that we’d like to see tested, and people get points for filling it out, and we can crown the top-alpha-tester-champion or something?
>
> - Something similar for qualified bug reports in JIRA?
>
> - Are there publications we should be talking to?
>
> - INSERT YOUR IDEA HERE
>
> * * *
>
> For all ideas we should consider the effort to set them up and maintain continuously.
>
> Let’s do this! :)
>
> Best
> Jan
> --
>
>
Re: Getting people to test CouchDB 2.0 alpha releases
Posted by Sebastian Rothbucher <se...@googlemail.com>.
Hi,
I think the docker image is a great start - you can hardly get any easier
(and there's an ansible thing on the way, too!). Maybe the command(s)
should be on the front page. In the end, for meaningful results I think you
have to have some knowledge/experience w/ Couch (or at least be willing 2
build it). Learning on alpha is no fun for sure - so I think tackling
existing applications might have a chance of doing the trick. I just did it
few days ago successfully, only have 2 report back ;-)
Best
Sebastian
On Thu, Jan 14, 2016 at 1:41 PM, Clemens Stolle <clemens.stolle@fastmail.com
> wrote:
> Thanks for your work on this Jan. :)
>
> Just a few ideas:
>
> Maybe we can turn the Google Doc into a simple friendly webpage? Might be
> more appealing and professional™ for people.
> Also, you’re right, alpha versions are always kind of scary for most in my
> experience.
>
> I’ve gotten some reports about issues with the 2.0-dev docker image, some
> are clearly problems with effing docker others are more on the side of
> CouchDB:
>
> Startup issues, most likely something wrong with the container config:
> https://github.com/klaemo/docker-couchdb/issues/41
> Config disabled in Fauxton, how to enable CORS:
> https://github.com/klaemo/docker-couchdb/issues/42
> Unrelated but interesting, admin user through env vars:
> https://github.com/klaemo/docker-couchdb/issues/43
>
> A public cluster would be lovely. Easy to do with DigitalOcean. Point a
> domain at it (like testing.couchdb.apache.org) and enable CORS so people
> can play with it.
>
> Also, it seems as if the cool kids use Slack or Discord to create new
> communication channels for OSS communities. Maybe that’s something to look
> into.
>
> Concerning client libraries: PouchDB tests against 1.6.1 and 2.0-dev with
> Travis using our Docker images. So that’s cool I think :)
>
> Have a nice day,
> Clemens
>
> > Am 14.01.2016 um 12:45 schrieb Jan Lehnardt <ja...@apache.org>:
> >
> > Dear marketing team (cc dev@),
> >
> > over the holiday break I made first build for CouchDB 2.0 available and
> have written up a document on how to get started with testing it at
> https://docs.google.com/document/d/1BtndYr-0KDQTqBSLVdJoR_8C5ObYjT1RBo_Qyh5ykdQ/edit#
> and I’ve also used Twitter to spread the word, and we’ve had this in last
> week’s weekly news.
> >
> > But we’re not seeing a lot of people giving these builds a spin. I’m not
> 100% on what to expect, but I would have expected a *little* more buzz
> around this :)
> >
> > Can you help brainstorm a few ideas on how to get this in front of more
> people, and how to get them to try out CouchDB 2.0 alpha?
> >
> > These things are circling in my back of the head:
> >
> > - Maybe the doc is too dense and not fun enough, or to badly written,
> please suggest any edits that you may think help (or scrap it and make an
> alternative, if you think it can’t be saved :)
> >
> > - Some people reply with “do you know when it is out of alpha and in
> beta?”, because they think alpha is to early to get into the game. I
> usually reply that we go beta as soon as they reported all the issues they
> found, but it didn’t help yet ;) — How do we convince those who *would*
> help, to help earlier?
> >
> > - Can we simplify the getting started experience?
> >
> > - Should we host a public cluster somewhere, that people can play with?
> >
> > - How do we get client library authors to test with CouchDB 2.0? (can we
> come up with a .travis.yml file that they can maybe use in a 2.0 branch of
> their tree (maybe PouchDB has something there already))
> >
> > - Can we simplify the procedure of how to report issues?
> >
> > - Can we put a feedback form into Fauxton? (maybe an embedded Google
> Form is enough?)
> >
> > - Can we put a web-chat pane into Fauxton, so people get a quick way to
> get into our IRC channel?
> >
> > - Can we track installations somehow, e.g. along the lines of “send
> anonymous data to the developers” where we can track the operating system /
> cluster config / maybe data sizes etc? (all opt-in of course).
> >
> > - Can we make this a mmopg? Maybe we draw up a huge matrix of test
> configurations that we’d like to see tested, and people get points for
> filling it out, and we can crown the top-alpha-tester-champion or something?
> >
> > - Something similar for qualified bug reports in JIRA?
> >
> > - Are there publications we should be talking to?
> >
> > - INSERT YOUR IDEA HERE
> >
> > * * *
> >
> > For all ideas we should consider the effort to set them up and maintain
> continuously.
> >
> > Let’s do this! :)
> >
> > Best
> > Jan
> > --
> >
> >
>
>
Re: Getting people to test CouchDB 2.0 alpha releases
Posted by Clemens Stolle <cl...@fastmail.com>.
Thanks for your work on this Jan. :)
Just a few ideas:
Maybe we can turn the Google Doc into a simple friendly webpage? Might be more appealing and professional™ for people.
Also, you’re right, alpha versions are always kind of scary for most in my experience.
I’ve gotten some reports about issues with the 2.0-dev docker image, some are clearly problems with effing docker others are more on the side of CouchDB:
Startup issues, most likely something wrong with the container config: https://github.com/klaemo/docker-couchdb/issues/41
Config disabled in Fauxton, how to enable CORS: https://github.com/klaemo/docker-couchdb/issues/42
Unrelated but interesting, admin user through env vars: https://github.com/klaemo/docker-couchdb/issues/43
A public cluster would be lovely. Easy to do with DigitalOcean. Point a domain at it (like testing.couchdb.apache.org) and enable CORS so people can play with it.
Also, it seems as if the cool kids use Slack or Discord to create new communication channels for OSS communities. Maybe that’s something to look into.
Concerning client libraries: PouchDB tests against 1.6.1 and 2.0-dev with Travis using our Docker images. So that’s cool I think :)
Have a nice day,
Clemens
> Am 14.01.2016 um 12:45 schrieb Jan Lehnardt <ja...@apache.org>:
>
> Dear marketing team (cc dev@),
>
> over the holiday break I made first build for CouchDB 2.0 available and have written up a document on how to get started with testing it at https://docs.google.com/document/d/1BtndYr-0KDQTqBSLVdJoR_8C5ObYjT1RBo_Qyh5ykdQ/edit# and I’ve also used Twitter to spread the word, and we’ve had this in last week’s weekly news.
>
> But we’re not seeing a lot of people giving these builds a spin. I’m not 100% on what to expect, but I would have expected a *little* more buzz around this :)
>
> Can you help brainstorm a few ideas on how to get this in front of more people, and how to get them to try out CouchDB 2.0 alpha?
>
> These things are circling in my back of the head:
>
> - Maybe the doc is too dense and not fun enough, or to badly written, please suggest any edits that you may think help (or scrap it and make an alternative, if you think it can’t be saved :)
>
> - Some people reply with “do you know when it is out of alpha and in beta?”, because they think alpha is to early to get into the game. I usually reply that we go beta as soon as they reported all the issues they found, but it didn’t help yet ;) — How do we convince those who *would* help, to help earlier?
>
> - Can we simplify the getting started experience?
>
> - Should we host a public cluster somewhere, that people can play with?
>
> - How do we get client library authors to test with CouchDB 2.0? (can we come up with a .travis.yml file that they can maybe use in a 2.0 branch of their tree (maybe PouchDB has something there already))
>
> - Can we simplify the procedure of how to report issues?
>
> - Can we put a feedback form into Fauxton? (maybe an embedded Google Form is enough?)
>
> - Can we put a web-chat pane into Fauxton, so people get a quick way to get into our IRC channel?
>
> - Can we track installations somehow, e.g. along the lines of “send anonymous data to the developers” where we can track the operating system / cluster config / maybe data sizes etc? (all opt-in of course).
>
> - Can we make this a mmopg? Maybe we draw up a huge matrix of test configurations that we’d like to see tested, and people get points for filling it out, and we can crown the top-alpha-tester-champion or something?
>
> - Something similar for qualified bug reports in JIRA?
>
> - Are there publications we should be talking to?
>
> - INSERT YOUR IDEA HERE
>
> * * *
>
> For all ideas we should consider the effort to set them up and maintain continuously.
>
> Let’s do this! :)
>
> Best
> Jan
> --
>
>
Re: Getting people to test CouchDB 2.0 alpha releases
Posted by Clemens Stolle <cl...@fastmail.com>.
Thanks for your work on this Jan. :)
Just a few ideas:
Maybe we can turn the Google Doc into a simple friendly webpage? Might be more appealing and professional™ for people.
Also, you’re right, alpha versions are always kind of scary for most in my experience.
I’ve gotten some reports about issues with the 2.0-dev docker image, some are clearly problems with effing docker others are more on the side of CouchDB:
Startup issues, most likely something wrong with the container config: https://github.com/klaemo/docker-couchdb/issues/41
Config disabled in Fauxton, how to enable CORS: https://github.com/klaemo/docker-couchdb/issues/42
Unrelated but interesting, admin user through env vars: https://github.com/klaemo/docker-couchdb/issues/43
A public cluster would be lovely. Easy to do with DigitalOcean. Point a domain at it (like testing.couchdb.apache.org) and enable CORS so people can play with it.
Also, it seems as if the cool kids use Slack or Discord to create new communication channels for OSS communities. Maybe that’s something to look into.
Concerning client libraries: PouchDB tests against 1.6.1 and 2.0-dev with Travis using our Docker images. So that’s cool I think :)
Have a nice day,
Clemens
> Am 14.01.2016 um 12:45 schrieb Jan Lehnardt <ja...@apache.org>:
>
> Dear marketing team (cc dev@),
>
> over the holiday break I made first build for CouchDB 2.0 available and have written up a document on how to get started with testing it at https://docs.google.com/document/d/1BtndYr-0KDQTqBSLVdJoR_8C5ObYjT1RBo_Qyh5ykdQ/edit# and I’ve also used Twitter to spread the word, and we’ve had this in last week’s weekly news.
>
> But we’re not seeing a lot of people giving these builds a spin. I’m not 100% on what to expect, but I would have expected a *little* more buzz around this :)
>
> Can you help brainstorm a few ideas on how to get this in front of more people, and how to get them to try out CouchDB 2.0 alpha?
>
> These things are circling in my back of the head:
>
> - Maybe the doc is too dense and not fun enough, or to badly written, please suggest any edits that you may think help (or scrap it and make an alternative, if you think it can’t be saved :)
>
> - Some people reply with “do you know when it is out of alpha and in beta?”, because they think alpha is to early to get into the game. I usually reply that we go beta as soon as they reported all the issues they found, but it didn’t help yet ;) — How do we convince those who *would* help, to help earlier?
>
> - Can we simplify the getting started experience?
>
> - Should we host a public cluster somewhere, that people can play with?
>
> - How do we get client library authors to test with CouchDB 2.0? (can we come up with a .travis.yml file that they can maybe use in a 2.0 branch of their tree (maybe PouchDB has something there already))
>
> - Can we simplify the procedure of how to report issues?
>
> - Can we put a feedback form into Fauxton? (maybe an embedded Google Form is enough?)
>
> - Can we put a web-chat pane into Fauxton, so people get a quick way to get into our IRC channel?
>
> - Can we track installations somehow, e.g. along the lines of “send anonymous data to the developers” where we can track the operating system / cluster config / maybe data sizes etc? (all opt-in of course).
>
> - Can we make this a mmopg? Maybe we draw up a huge matrix of test configurations that we’d like to see tested, and people get points for filling it out, and we can crown the top-alpha-tester-champion or something?
>
> - Something similar for qualified bug reports in JIRA?
>
> - Are there publications we should be talking to?
>
> - INSERT YOUR IDEA HERE
>
> * * *
>
> For all ideas we should consider the effort to set them up and maintain continuously.
>
> Let’s do this! :)
>
> Best
> Jan
> --
>
>