couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: [discuss] couchapp.org down, couchapp.org spammed
Date Sun, 01 Dec 2013 00:53:58 GMT
On Sun, Dec 1, 2013 at 1:20 AM, Russell Branca <chewbranca@apache.org>wrote:

> In its current form, couchapp.org is a relic that has been mostly
> abandoned
> and is not maintainable by the community. I strongly feel we should move
> the couchapp documentation into official documentation. I see two relevant
> points of interest in this discussion. First is the notion of couchapps as
> the self contained application platform that utilizes show/list functions,
> and whether these should be included in CouchDB. I don't think this is the
> important issue at hand.
>

> The bigger issue is that the defacto method of defining design documents is
> to use one of the many "couchapp" tools, and the only place this is
> documented as a whole is couchapp.org. This is a disservice to the
> community, and one that needs to be resolved. This is a constant source of
> confusion to new users who quickly realize the futility of defining design
> docs in the browser, and get lost when told "just use a couchapp", and then
> they inevitably end up clicking on the top google result for "couchapp",
> couchapp.org. We need to have this properly documented in the official
> documentation so that the process is fully defined for new users.
>
> A couple of options for approach would be to formalize the folder
> definition of a couchapp and list tools known to be compatible, or to
> officially bless a tool like Erica. While I do want to see Fauxton provide
> powerful editors for all the different function types, I don't think this
> is sufficient as people typically want to keep their design docs raw code
> under SCM. Whatever approach is taken, I think the number one priority here
> is ensuring proper documentation explaining to users best practices for
> defining and maintaining design docs.
>
>
>
> +1

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message