...@gmail.com]
Sent: Friday, December 20, 2013 11:39 AM
To: dev@cordova.apache.org
Subject: Re: Deleting Plugin Docs
I'm a bit lost
Is the eventual goal to build the docs as a single website (docs.cordova.io)
with multiple repos cordova-docs repo and plugin repos?
On Fri, Dec 20, 2013 at 11:00 AM, Wargo
plugin-centric docs, right?
John M. Wargo
Twitter: @johnwargo
-Original Message-
From: Carlos Santana [mailto:csantan...@gmail.com]
Sent: Friday, December 20, 2013 11:39 AM
To: dev@cordova.apache.org
Subject: Re: Deleting Plugin Docs
I'm a bit lost
Is the eventual goal to build
Thanks!
The problem I saw with the full examples, is that they are copy pastes of
the Quick Examples, but put within an html page and an onDeviceReady
callback. Given that the default app templates already have this, is it
really necessary to have it in every example? You can still copy paste
We'll point them to master as soon as the docs exist on master.
On Thu, Dec 19, 2013 at 4:13 PM, Marcel Kinard cmarc...@gmail.com wrote:
+1 to Michael's comments.
And I know it is a bit too early to do this, but the links to the docs on
github should point to the master branch, not the dev
...@google.com] On Behalf Of Andrew Grieve
Sent: Wednesday, December 18, 2013 10:40 PM
To: dev
Subject: Fwd: Deleting Plugin Docs
This is now done! Woo! No more having plugins code separate from their docs
(I hear we might even get tests to live within plugin repos in the next
while too!).
I tried
:40 PM
To: dev
Subject: Fwd: Deleting Plugin Docs
This is now done! Woo! No more having plugins code separate from their docs
(I hear we might even get tests to live within plugin repos in the next
while too!).
I tried to be diligent, but it's possible I made mistakes along the way.
You can
Message-
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
Grieve
Sent: Wednesday, December 18, 2013 10:40 PM
To: dev
Subject: Fwd: Deleting Plugin Docs
This is now done! Woo! No more having plugins code separate from their docs
(I hear we might even get tests
Grieve
Sent: Wednesday, December 18, 2013 10:40 PM
To: dev
Subject: Fwd: Deleting Plugin Docs
This is now done! Woo! No more having plugins code separate from their
docs
(I hear we might even get tests to live within plugin repos in the next
while too!).
I tried to be diligent
-Original Message-
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of
Andrew
Grieve
Sent: Wednesday, December 18, 2013 10:40 PM
To: dev
Subject: Fwd: Deleting Plugin Docs
This is now done! Woo! No more having plugins code separate from their
docs
: Wednesday, December 18, 2013 10:40 PM
To: dev
Subject: Fwd: Deleting Plugin Docs
This is now done! Woo! No more having plugins code separate from
their
docs
(I hear we might even get tests to live within plugin repos in the
next
while too!).
I tried to be diligent
-Original Message-
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of
Andrew
Grieve
Sent: Wednesday, December 18, 2013 10:40 PM
To: dev
Subject: Fwd: Deleting Plugin Docs
This is now done! Woo! No more having plugins code separate from their
docs
(I
Twitter: @johnwargo
-Original Message-
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of
Andrew
Grieve
Sent: Wednesday, December 18, 2013 10:40 PM
To: dev
Subject: Fwd: Deleting Plugin Docs
This is now done! Woo! No more having
Nice Andrew.
I think the Plugins API page is a good start. We can iterate on it
to improve the experience.
Personally, I would rather not have cut out the quick examples, full
examples, etc. Some of the most positive feedback for our
documentation is that it's thorough and copy paste ready.
+1 to Michael's comments.
And I know it is a bit too early to do this, but the links to the docs on
github should point to the master branch, not the dev branch, correct?
I don't think there is anything wrong with big docs, as long as they are useful
and navigable.
This is now done! Woo! No more having plugins code separate from their docs
(I hear we might even get tests to live within plugin repos in the next
while too!).
I tried to be diligent, but it's possible I made mistakes along the way.
You can see the result on the edge version of the docs:
Michael - Just to clarify, you're suggesting that we put all docs-related
files *except* the main README.md within docs/? This plays well with
github, but wanted to clarify. Maybe translations can one day go in
docs_translated/$LANGUAGE
## project-name/README.md
The file should be targeted
Issue created: https://issues.apache.org/jira/browse/CB-5658
Brian - no need to align this with plugins.cordova.io release. Until then,
we can point at the github renderings of the READMEs
Michael - Just to clarify, you're suggesting that we put all docs-related
files *except* the main README.md
SGTM. And where the plugin docs are removed from cordova-docs, there should be
instructions on where consumers can find the relocated plugin docs.
I would like to:
1. Delete the docs/ directory from all plugins
- They contain stale copies of what's in cordova-docs
2. Move plugin information found in cordova-docs into a single README.md
file within the respective plugin repos
3. Delete the API Reference section of cordova-docs
4. Add a
2. Move plugin information found in cordova-docs into a single README.md
file within the respective plugin repos
And also remove the /cordova/ folder from cordova-docs, right? This way
there will be only one single location for a plugin's documentation (the
README.md file inside that plugin
Mike, actually I think with this proposal it should be easier than ever to
match plugin to docs specific to its version.
The documentation would come bundled with the plugin, so you can find the
README.md alongside wherever your plugin code resides, be that an old
download, a plugman install, or
RE my last suggest about CLI command for plugin docs, I'm now thinking it
would be better to do something like we plan for tests: ship an app that
hosts the docs based on whichever plugins you have installed. Perhaps the
test app should even do both tasks?
On Fri, Dec 13, 2013 at 2:06 PM,
On Fri, Dec 13, 2013 at 2:08 PM, Michal Mocny mmo...@chromium.org wrote:
RE my last suggest about CLI command for plugin docs, I'm now thinking it
would be better to do something like we plan for tests: ship an app that
hosts the docs based on whichever plugins you have installed. Perhaps the
+1
(we should time this for the plugins.cordova.io refactor/release so we
don't have a period of zero published plugin documentation)
On Sat, Dec 14, 2013 at 6:47 AM, Andrew Grieve agri...@chromium.org wrote:
On Fri, Dec 13, 2013 at 2:08 PM, Michal Mocny mmo...@chromium.org wrote:
RE my
Hi Andrew,
I like this plan. It aligns perfectly with where I want the docs to go.
I would rather see each plugin use a doc/index.md file for the API
documentation. However, since plugins.cordova.io should auto-generate the
README.md to HTML, it makes sense to use that file instead. However, I
ya I like that plan too
README should just be simple description of what it is and how to install
does raise the query: should plugin install automate config.xml tags?
On Sat, Dec 14, 2013 at 8:22 AM, Michael Brooks mich...@michaelbrooks.cawrote:
Hi Andrew,
I like this plan. It aligns
+1 from me, makes sense
On Fri, Dec 13, 2013 at 2:07 PM, Brian LeRoux b...@brian.io wrote:
ya I like that plan too
README should just be simple description of what it is and how to install
does raise the query: should plugin install automate config.xml tags?
On Sat, Dec 14, 2013 at 8:22
love the idea.
On Dec 13, 2013 3:24 PM, Shazron shaz...@gmail.com wrote:
+1 from me, makes sense
On Fri, Dec 13, 2013 at 2:07 PM, Brian LeRoux b...@brian.io wrote:
ya I like that plan too
README should just be simple description of what it is and how to install
does raise the
28 matches
Mail list logo
