devo-ps / docs.devo.ps Goto Github PK

Add support for responsive design (for now pretty broken on mobile devices).

Where's our API reference? Are we guys still using Carte? If so, should we update it to work w/ metalsmith (and add automated build w/ TravisCI?).

Currently, some of the configuration variables have a "Valid value" field. I am wondering if we shouldn't simply mention this in the description OR change the format of the value (right now it's very awkwardly worded: "Valid values: Either of alias / root").

Where can I edit these values @zbal ?

Build process was broken because of new gulp version (same as devo-ps.github.io:#56 ).

Why are we spending so much time explaining what each service is? An excerpt for CouchDB for example:

A Database for the Web

CouchDB is a database that completely embraces the web. Store your data with JSON documents. Access your documents and query your indexes with your web browser, via HTTP. Index, combine, and transform your documents with JavaScript. CouchDB works well with modern web and mobile apps. You can even serve web apps directly out of CouchDB. And you can distribute your data, or your apps, efficiently using CouchDB’s incremental replication. CouchDB supports master-master setups with automatic conflict detection.

CouchDB comes with a suite of features, such as on-the-fly document transformation and real-time change notifications, that makes web app development a breeze. It even comes with an easy to use web administration console. You guessed it, served up directly out of CouchDB! We care a lot about distributed scaling. CouchDB is highly available and partition tolerant, but is also eventually consistent. And we care a lot about your data. CouchDB has a fault-tolerant storage engine that puts the safety of your data first.

That's a truckload of content that I'm not (ever) gonna read. When I land on the page, I know what service I want to use, potentially I may have stuff I need to check in the CouchDB documentation (and we can link to it), but I would be in favor of completely removing that section.

@JuhaS @zbal Thoughts?

In python documentation there is expand-button on the configuration structure, but clicking it does nothing.

Screenshot:

Need to mock and style the variables page;

1. Add a variables branch,
2. Enable the variables tab on repos there,
3. Build a simple table and filter box at the top with the list of all the variables defined, and their values and protected/private flags (I'll style the mock, you can ignore that feature for now in production).

We're missing the details command you make allusion to in the documentation for tasks. http://docs.devo.ps/manual/CLI/

Write documentation on how to use cron triggers and possibly some common cron examples and link to more in depth information.

Add a filter for the tasks and configuration tables, allowing the user to filter by task ID and variable name.

• We need to add content to python and uwsgi pages.
• Also review that all the options are listed there.

Not sure what we're supposed to have in there, or if it's even still being used: http://docs.devo.ps/services/common/

At this stage, it looks more or less like a wrapper for Git/GitHub. Shouldn't we be adding a Git or GitHub package (not sure if the methods you have for it work for all Git repos) and let users know it's a default package?

The config tree is meant to reproduce what the config of the service would be if defined in a node.

Hover on key show the full description, only key and default value are showen. Clicking on the key redirect to the full config about that element later in the service documentation.

FIrst pass has been pushed in config_tree branch, styling is to be done, re-organisation of the elements may be required.

The CI currently doesn't seem to deploy my more recent changes/updates.

Where is the CI defined? I don't want you to do it, I should be able to take over that part.

Currently, the documentation for nodes and providers doesn't include any mention of the recommended/possible images. What is it?

Need to have a section in each of the provider that explains how to create the API keys for each of them, possibly including a few screenshot of the respective interfaces as well as the required permissions.

I just wiped out two folders (references/ and concepts/) that were renamed a few days ago. From what I can tell, we push to gh-pages without wiping out files / folders that have been deleted, meaning that content that got removed becomes stale.

I think we should review how this works for all static websites.

Currently the metalsmith branch doesn't include either of CNAME, ggl validation link, etc. It prevents from migrating from the current build script to the metalsmith example we provided on our blog (which seems more suitable on the long term).

Update the build process of metalsmith to include all the required info so we can wipe out the master branch and push fresh updates every time.

Need screenshot / tutorial on how to create API keys for the various providers.

• linode
• EC2 / IAM
• DigitalOcean
• Rackspace

• List all supported events
• Describe what they mean (be specific on what is the processing sequence)