1.0 Roadmap

[justinbmeyer]

this is here because milestones don't support markdown as well as issues

This issue represents what could be considered an ideal "Documentation Product".

Goals:

A core product that focuses on reading files, converting that to something like a docMap and exporting that to consumable format.

The core product should be more or less agnostic to the types or format of those files, and to the final format. Instead it should focus on:

• extensibility - make it easy to import custom tags, themes, and generators
• development vs production concerns - make it easy to document locally, not on the "site repo" itself, including demo pages, but make it easily deploy-able.
• user submitted content - make it possible to allow users to submit changes
• happy path for git and npm users

With this core product in place, we might likely create two different extensions that can work together: a "js" and "css" extension. They would focus on meeting the needs of their user bases.

High-level tasks

• Branding

We need a name for the core product. Ideally, it should fit in well with "DocumentJS" and "DocumentCSS".

• Design new docConfig

I think something like the following in package.json for each released version:

"devDependencies": {
  "documentit": "1.1.0"
},
"documentit": {
  "extensions" : {
    "bitovi-theme": "0.1.X",
    "documentcss": "1.1.X",
    "documentjs": "1.2.X"
  }
}

And then something like this for the main site:

"devDependencies": {
  "documentit": "1.2.0"
},
"documentit": {
  "versions": {
      "npmVersions" : {
      "can": "MAX_MINOR( >1.2 <=2.2 )"
    },
    "2.3.0-pre" : "https://github.com/bitovi/canjs/tree/minor",
    "3.0.0-pre" : "https://github.com/bitovi/canjs/tree/major",
   }

  "defaultVersion": "
}

• __Implement

[ramblinjan]

Separate Tasks for Users: Creating Content and Customizing Site

Ideally, workflow, documentation, and design will take into account that actually documenting or creating content is a task that should generally happen independently of customizing a site. Currently they often happen in parallel and I think this has proven confusing for people unfamiliar with documentjs (and especially designers).

[chasenlehara]

@justinbmeyer, given the existence of bit-docs, it’d be really nice to hear your thoughts on how it relates to the future of DocumentJS.

[justinbmeyer]

it will replace DocumentJS when we have time to polish it off.