Today Torrey updated dojotoolkit.org to point to the reference doc for 1.7.
As always, livedocs.dojotoolkit.org is the latest version of the doc,
meaning that it currently contains info for code available in the upcoming
1.8 release, but not in 1.7.

I and some others have been doing a lot of work that past month cleaning up
our reference doc. But we can't do it all. If anyone wants to help, it
would be greatly appreciated. There's a bunch of work that can be done
to make it better.

The docs continue to be editable through livedocs.dojotoolkit.org, but also
they can now also be edited directly, see instructions which (for the time
being) are in http://oksoclap.com/22eEx9Hh4Q. Committers can directly
check in the changes, and (theoretically) non-committers can clone the docs
repository to their own github account, make changes, and then send a pull
request.

A partial list of things to do for the reference doc, besides the obvious
task of just going through and fixing errors/ommissions, is:


*1. Fix broken examples and convert static example text into something
runnable by codeglass.*

For example, something like

.. js ::

dojo.forEach([1,3,5 7], function(){ /* do something */});

can be converted to

.. code-example ::

.. js ::

dojo.forEach([1,3,5 7], function(n){ console.log(n); });

at which point we can run the example, and therefore notice and fix the
syntax error. Runnable examples are also better for people using the doc.


*2. upgrade examples (AMD format, new API's, fixing indentation)*

Eventually all of our examples need to be converted to AMD format, with
minimal dependencies, and to use the new APIS like dojo/query and dojo/on.
Now is a good time to get a head start. Admittedly the conversion to
minimal dependencies is a bit premature as it's referencing files in
dojo/_base (ex: dojo/_base/array) that will disappear in 2.0, to be
replaced with something else (perhaps dojo/array, but still undecided).
But those future changes can be mostly handled with a global search/replace.

Also, note that the documentation (including code examples) should use
spaces instead of tabs.


*3. grammar and spelling*

There are still some spelling mistakes on the pages, and grammar errors too.

Obviously one way of fixing these problems is to read over the pages.
Another is to load each page's HTML (I threw a copy on
http://bill.dojotoolkit.org/refdoc.tar.gz) in MS Word, and then hit the
return key (or any key). Word will then point out errors (along with some
things that aren't errors), which you can then correct in the source .rst
files. Don't edit the pages in Word or your changes will be lost.


*4. removing duplicate information*

API information available from http://dojotoolkit.org/api/ shouldn't be in
the doc. Rather, the doc should link to this info via code like:

.. api-inline :: dijit.Dialog

The API doc admittedly currently has some problems (in particular,
(non-function) attributes aren't showing up?) but that will be fixed
eventually.


*5. Splitting long lines*

Now that we are using "normal" editors for editing the doc, it's easier to
edit pages if the lines are wrapped (at around maybe 120 characters or
less). I'm sure there are many ways to do this; I ran the following regex
repeatedly, until it had no more matches:

converting: ^([a-zA-Z].*[\.\?\!]) +([a-zA-Z])

into: $1\n$2
It's not perfect because it doesn't affect lists or tables correctly, but
it's a start. The results should be checked over before they are checked
in.


*6. check that pragmas like .. js :: are right*

Check with the examples is that they use the right pragmas. It should be

.. js ::

for javascript code, without a surrounding <script> tag.

.. css ::

for CSS code, without a surrounding <style> tag

and

.. html ::

for anything with tags like <div>, even if inside that tag it has
javascript, ex: <script type="dojo/method" ...>


I'm sure there's something else that I'll think of right after sending this
message, but anyway that's a start.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111223/d82495b6/attachment.htm

Search Discussions

  • Adam L. Peller at Dec 22, 2011 at 10:49 pm
    First of all, a big thanks to Torrey for moving things forward on the site.
    Now that the infrastructure is in place, I'm hoping an iterative process
    to push updates will get us where we need to go without too much pain. At
    this point, almost any change is an improvement. A random click brought me
    to an error, though, so I'm thinking we may still have some kinks to work
    out.

    http://dojotoolkit.org/reference-guide/#dojo-base -- under "Utilities"
    click on Dojo Build System and get a 404

    Quickstart guides is under Dijit. Is this intentional? If not, I think
    this one's easily fixed on the wiki.

    Also, the bulk of the content is buried behind the "checkout the full
    content" link as if it's a footnote. What might be a better way to
    organize this page?

    -Adam


    2011/12/22 Bill Keese <bill at dojotoolkit.org>
    Today Torrey updated dojotoolkit.org to point to the reference doc for
    1.7. As always, livedocs.dojotoolkit.org is the latest version of the
    doc, meaning that it currently contains info for code available in the
    upcoming 1.8 release, but not in 1.7.

    I and some others have been doing a lot of work that past month cleaning
    up our reference doc. But we can't do it all. If anyone wants to help,
    it would be greatly appreciated. There's a bunch of work that can be
    done to make it better.

    The docs continue to be editable through livedocs.dojotoolkit.org, but
    also they can now also be edited directly, see instructions which (for the
    time being) are in http://oksoclap.com/22eEx9Hh4Q. Committers can
    directly check in the changes, and (theoretically) non-committers can clone
    the docs repository to their own github account, make changes, and then
    send a pull request.

    A partial list of things to do for the reference doc, besides the obvious
    task of just going through and fixing errors/ommissions, is:


    *1. Fix broken examples and convert static example text into something
    runnable by codeglass.*

    For example, something like

    .. js ::

    dojo.forEach([1,3,5 7], function(){ /* do something */});

    can be converted to

    .. code-example ::

    .. js ::

    dojo.forEach([1,3,5 7], function(n){ console.log(n); });

    at which point we can run the example, and therefore notice and fix the
    syntax error. Runnable examples are also better for people using the doc.


    *2. upgrade examples (AMD format, new API's, fixing indentation)*

    Eventually all of our examples need to be converted to AMD format, with
    minimal dependencies, and to use the new APIS like dojo/query and dojo/on.
    Now is a good time to get a head start. Admittedly the conversion to
    minimal dependencies is a bit premature as it's referencing files in
    dojo/_base (ex: dojo/_base/array) that will disappear in 2.0, to be
    replaced with something else (perhaps dojo/array, but still undecided).
    But those future changes can be mostly handled with a global search/replace.

    Also, note that the documentation (including code examples) should use
    spaces instead of tabs.


    *3. grammar and spelling*

    There are still some spelling mistakes on the pages, and grammar errors
    too.

    Obviously one way of fixing these problems is to read over the pages.
    Another is to load each page's HTML (I threw a copy on
    http://bill.dojotoolkit.org/refdoc.tar.gz) in MS Word, and then hit the
    return key (or any key). Word will then point out errors (along with some
    things that aren't errors), which you can then correct in the source .rst
    files. Don't edit the pages in Word or your changes will be lost.


    *4. removing duplicate information*

    API information available from http://dojotoolkit.org/api/ shouldn't be
    in the doc. Rather, the doc should link to this info via code like:

    .. api-inline :: dijit.Dialog

    The API doc admittedly currently has some problems (in particular,
    (non-function) attributes aren't showing up?) but that will be fixed
    eventually.


    *5. Splitting long lines*

    Now that we are using "normal" editors for editing the doc, it's easier to
    edit pages if the lines are wrapped (at around maybe 120 characters or
    less). I'm sure there are many ways to do this; I ran the following regex
    repeatedly, until it had no more matches:

    converting: ^([a-zA-Z].*[\.\?\!]) +([a-zA-Z])

    into: $1\n$2
    It's not perfect because it doesn't affect lists or tables correctly, but
    it's a start. The results should be checked over before they are checked
    in.


    *6. check that pragmas like .. js :: are right*

    Check with the examples is that they use the right pragmas. It should be

    .. js ::

    for javascript code, without a surrounding <script> tag.

    .. css ::

    for CSS code, without a surrounding <style> tag

    and

    .. html ::

    for anything with tags like <div>, even if inside that tag it has
    javascript, ex: <script type="dojo/method" ...>


    I'm sure there's something else that I'll think of right after sending
    this message, but anyway that's a start.

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111222/db312061/attachment.htm
  • Bill Keese at Dec 23, 2011 at 1:16 am
    That quickstart change is from phiggins, in
    https://github.com/dojo/docs/commit/da568048469bf3925aec6bbbcbb3aa89b73a8630#index.rst.
    I agree it's weird; I think he moved the quickstart reference from the
    paragraph down to the bulleted list, which makes it misleading as though
    it's a quickstart just for dijit. There is also a link to the quick-start
    information from the introduction on that top page.

    I'm confused about http://dojotoolkit.org/reference-guide/ though because
    the ending (Utilities and Miscellaneous) section doesn't match the ending
    of the source rst file, https://github.com/dojo/docs/blob/master/index.rst.
    The source rst file doesn't have that broken link.

    Where is this "checkout the full content" link?

    2011/12/23 Adam L. Peller <adam at peller.org>
    First of all, a big thanks to Torrey for moving things forward on the
    site. Now that the infrastructure is in place, I'm hoping an iterative
    process to push updates will get us where we need to go without too much
    pain. At this point, almost any change is an improvement. A random click
    brought me to an error, though, so I'm thinking we may still have some
    kinks to work out.

    http://dojotoolkit.org/reference-guide/#dojo-base -- under "Utilities"
    click on Dojo Build System and get a 404

    Quickstart guides is under Dijit. Is this intentional? If not, I think
    this one's easily fixed on the wiki.

    Also, the bulk of the content is buried behind the "checkout the full
    content" link as if it's a footnote. What might be a better way to
    organize this page?

    -Adam


    2011/12/22 Bill Keese <bill at dojotoolkit.org>
    Today Torrey updated dojotoolkit.org to point to the reference doc for
    1.7. As always, livedocs.dojotoolkit.org is the latest version of the
    doc, meaning that it currently contains info for code available in the
    upcoming 1.8 release, but not in 1.7.

    I and some others have been doing a lot of work that past month cleaning
    up our reference doc. But we can't do it all. If anyone wants to help,
    it would be greatly appreciated. There's a bunch of work that can be
    done to make it better.

    The docs continue to be editable through livedocs.dojotoolkit.org, but
    also they can now also be edited directly, see instructions which (for the
    time being) are in http://oksoclap.com/22eEx9Hh4Q. Committers can
    directly check in the changes, and (theoretically) non-committers can clone
    the docs repository to their own github account, make changes, and then
    send a pull request.

    A partial list of things to do for the reference doc, besides the obvious
    task of just going through and fixing errors/ommissions, is:


    *1. Fix broken examples and convert static example text into something
    runnable by codeglass.*

    For example, something like

    .. js ::

    dojo.forEach([1,3,5 7], function(){ /* do something */});

    can be converted to

    .. code-example ::

    .. js ::

    dojo.forEach([1,3,5 7], function(n){ console.log(n); });

    at which point we can run the example, and therefore notice and fix the
    syntax error. Runnable examples are also better for people using the doc.


    *2. upgrade examples (AMD format, new API's, fixing indentation)*

    Eventually all of our examples need to be converted to AMD format, with
    minimal dependencies, and to use the new APIS like dojo/query and dojo/on.
    Now is a good time to get a head start. Admittedly the conversion to
    minimal dependencies is a bit premature as it's referencing files in
    dojo/_base (ex: dojo/_base/array) that will disappear in 2.0, to be
    replaced with something else (perhaps dojo/array, but still undecided).
    But those future changes can be mostly handled with a global search/replace.

    Also, note that the documentation (including code examples) should use
    spaces instead of tabs.


    *3. grammar and spelling*

    There are still some spelling mistakes on the pages, and grammar errors
    too.

    Obviously one way of fixing these problems is to read over the pages.
    Another is to load each page's HTML (I threw a copy on
    http://bill.dojotoolkit.org/refdoc.tar.gz) in MS Word, and then hit the
    return key (or any key). Word will then point out errors (along with some
    things that aren't errors), which you can then correct in the source .rst
    files. Don't edit the pages in Word or your changes will be lost.


    *4. removing duplicate information*

    API information available from http://dojotoolkit.org/api/ shouldn't be
    in the doc. Rather, the doc should link to this info via code like:

    .. api-inline :: dijit.Dialog

    The API doc admittedly currently has some problems (in particular,
    (non-function) attributes aren't showing up?) but that will be fixed
    eventually.


    *5. Splitting long lines*

    Now that we are using "normal" editors for editing the doc, it's easier
    to edit pages if the lines are wrapped (at around maybe 120 characters or
    less). I'm sure there are many ways to do this; I ran the following regex
    repeatedly, until it had no more matches:

    converting: ^([a-zA-Z].*[\.\?\!]) +([a-zA-Z])

    into: $1\n$2
    It's not perfect because it doesn't affect lists or tables correctly, but
    it's a start. The results should be checked over before they are checked
    in.


    *6. check that pragmas like .. js :: are right*

    Check with the examples is that they use the right pragmas. It should
    be

    .. js ::

    for javascript code, without a surrounding <script> tag.

    .. css ::

    for CSS code, without a surrounding <style> tag

    and

    .. html ::

    for anything with tags like <div>, even if inside that tag it has
    javascript, ex: <script type="dojo/method" ...>


    I'm sure there's something else that I'll think of right after sending
    this message, but anyway that's a start.

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111223/1dd1b389/attachment-0001.htm
  • Bill Keese at Dec 24, 2011 at 10:19 pm
    PS: a few more possible documentation tasks:

    - fix broken links and other errors reported in
    http://bill.dojotoolkit.org/warnings.txt (the file generated from "make
    data html" in rstwiki/exports)
    - standardize naming, capitalization, and formatting for proper names and
    identifiers. Correct examples, according to IRC conversation a few weeks
    ago: JavaScript, Dijit, Dojo, DOM node, ``<div>``, ``href``,
    ``getChildren()``

    - add any missing pages, like for all the new dom*.js modules. Note that
    there's a bug with livedocs.dojotoolkit.org and it doesn't add new pages to
    the github repository (http://github.com/dojo/docs), so if you add a new
    page via livedocs.dojotoolkit.org be sure to ask phiggins to add your page
    to github manually.

    - require the parser and add :djConfig: parseOnLoad: true (right below
    the code-example directive ) for all declarative


    See also Pete's howto guide about our reST formatting:
    https://github.com/phiggins42/rstwiki/blob/master/sample_data/index.rst

    On Fri, Dec 23, 2011 at 10:50 AM, Bill Keese wrote:

    Today Torrey updated dojotoolkit.org to point to the reference doc for
    1.7. As always, livedocs.dojotoolkit.org is the latest version of the
    doc, meaning that it currently contains info for code available in the
    upcoming 1.8 release, but not in 1.7.

    I and some others have been doing a lot of work that past month cleaning
    up our reference doc. But we can't do it all. If anyone wants to help,
    it would be greatly appreciated. There's a bunch of work that can be
    done to make it better.

    The docs continue to be editable through livedocs.dojotoolkit.org, but
    also they can now also be edited directly, see instructions which (for the
    time being) are in http://oksoclap.com/22eEx9Hh4Q. Committers can
    directly check in the changes, and (theoretically) non-committers can clone
    the docs repository to their own github account, make changes, and then
    send a pull request.

    A partial list of things to do for the reference doc, besides the obvious
    task of just going through and fixing errors/ommissions, is:


    *1. Fix broken examples and convert static example text into something
    runnable by codeglass.*

    For example, something like

    .. js ::

    dojo.forEach([1,3,5 7], function(){ /* do something */});

    can be converted to

    .. code-example ::

    .. js ::

    dojo.forEach([1,3,5 7], function(n){ console.log(n); });

    at which point we can run the example, and therefore notice and fix the
    syntax error. Runnable examples are also better for people using the doc.


    *2. upgrade examples (AMD format, new API's, fixing indentation)*

    Eventually all of our examples need to be converted to AMD format, with
    minimal dependencies, and to use the new APIS like dojo/query and dojo/on.
    Now is a good time to get a head start. Admittedly the conversion to
    minimal dependencies is a bit premature as it's referencing files in
    dojo/_base (ex: dojo/_base/array) that will disappear in 2.0, to be
    replaced with something else (perhaps dojo/array, but still undecided).
    But those future changes can be mostly handled with a global search/replace.

    Also, note that the documentation (including code examples) should use
    spaces instead of tabs.


    *3. grammar and spelling*

    There are still some spelling mistakes on the pages, and grammar errors
    too.

    Obviously one way of fixing these problems is to read over the pages.
    Another is to load each page's HTML (I threw a copy on
    http://bill.dojotoolkit.org/refdoc.tar.gz) in MS Word, and then hit the
    return key (or any key). Word will then point out errors (along with some
    things that aren't errors), which you can then correct in the source .rst
    files. Don't edit the pages in Word or your changes will be lost.


    *4. removing duplicate information*

    API information available from http://dojotoolkit.org/api/ shouldn't be
    in the doc. Rather, the doc should link to this info via code like:

    .. api-inline :: dijit.Dialog

    The API doc admittedly currently has some problems (in particular,
    (non-function) attributes aren't showing up?) but that will be fixed
    eventually.


    *5. Splitting long lines*

    Now that we are using "normal" editors for editing the doc, it's easier to
    edit pages if the lines are wrapped (at around maybe 120 characters or
    less). I'm sure there are many ways to do this; I ran the following regex
    repeatedly, until it had no more matches:

    converting: ^([a-zA-Z].*[\.\?\!]) +([a-zA-Z])

    into: $1\n$2
    It's not perfect because it doesn't affect lists or tables correctly, but
    it's a start. The results should be checked over before they are checked
    in.


    *6. check that pragmas like .. js :: are right*

    Check with the examples is that they use the right pragmas. It should be

    .. js ::

    for javascript code, without a surrounding <script> tag.

    .. css ::

    for CSS code, without a surrounding <style> tag

    and

    .. html ::

    for anything with tags like <div>, even if inside that tag it has
    javascript, ex: <script type="dojo/method" ...>


    I'm sure there's something else that I'll think of right after sending
    this message, but anyway that's a start.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111225/ceba3c19/attachment.htm
  • Bill Keese at Dec 25, 2011 at 6:42 pm
    PPS: oh I forgot documenting customizing widgets' look and feel (i.e.
    documenting CSS, although nowadays it may be more important to document
    customization via changing variables.less).
    On Sun, Dec 25, 2011 at 12:19 PM, Bill Keese wrote:

    PS: a few more possible documentation tasks:

    - fix broken links and other errors reported in
    http://bill.dojotoolkit.org/warnings.txt (the file generated from "make
    data html" in rstwiki/exports)
    - standardize naming, capitalization, and formatting for proper names and
    identifiers. Correct examples, according to IRC conversation a few weeks
    ago: JavaScript, Dijit, Dojo, DOM node, ``<div>``, ``href``,
    ``getChildren()``

    - add any missing pages, like for all the new dom*.js modules. Note that
    there's a bug with livedocs.dojotoolkit.org and it doesn't add new pages
    to the github repository (http://github.com/dojo/docs), so if you add a
    new page via livedocs.dojotoolkit.org be sure to ask phiggins to add your
    page to github manually.

    - require the parser and add :djConfig: parseOnLoad: true (right below
    the code-example directive ) for all declarative


    See also Pete's howto guide about our reST formatting:
    https://github.com/phiggins42/rstwiki/blob/master/sample_data/index.rst

    On Fri, Dec 23, 2011 at 10:50 AM, Bill Keese wrote:

    Today Torrey updated dojotoolkit.org to point to the reference doc for
    1.7. As always, livedocs.dojotoolkit.org is the latest version of the
    doc, meaning that it currently contains info for code available in the
    upcoming 1.8 release, but not in 1.7.

    I and some others have been doing a lot of work that past month cleaning
    up our reference doc. But we can't do it all. If anyone wants to help,
    it would be greatly appreciated. There's a bunch of work that can be
    done to make it better.

    The docs continue to be editable through livedocs.dojotoolkit.org, but
    also they can now also be edited directly, see instructions which (for the
    time being) are in http://oksoclap.com/22eEx9Hh4Q. Committers can
    directly check in the changes, and (theoretically) non-committers can clone
    the docs repository to their own github account, make changes, and then
    send a pull request.

    A partial list of things to do for the reference doc, besides the obvious
    task of just going through and fixing errors/ommissions, is:


    *1. Fix broken examples and convert static example text into something
    runnable by codeglass.*

    For example, something like

    .. js ::

    dojo.forEach([1,3,5 7], function(){ /* do something */});

    can be converted to

    .. code-example ::

    .. js ::

    dojo.forEach([1,3,5 7], function(n){ console.log(n); });

    at which point we can run the example, and therefore notice and fix the
    syntax error. Runnable examples are also better for people using the doc.


    *2. upgrade examples (AMD format, new API's, fixing indentation)*

    Eventually all of our examples need to be converted to AMD format, with
    minimal dependencies, and to use the new APIS like dojo/query and dojo/on.
    Now is a good time to get a head start. Admittedly the conversion to
    minimal dependencies is a bit premature as it's referencing files in
    dojo/_base (ex: dojo/_base/array) that will disappear in 2.0, to be
    replaced with something else (perhaps dojo/array, but still undecided).
    But those future changes can be mostly handled with a global search/replace.

    Also, note that the documentation (including code examples) should use
    spaces instead of tabs.


    *3. grammar and spelling*

    There are still some spelling mistakes on the pages, and grammar errors
    too.

    Obviously one way of fixing these problems is to read over the pages.
    Another is to load each page's HTML (I threw a copy on
    http://bill.dojotoolkit.org/refdoc.tar.gz) in MS Word, and then hit the
    return key (or any key). Word will then point out errors (along with some
    things that aren't errors), which you can then correct in the source .rst
    files. Don't edit the pages in Word or your changes will be lost.


    *4. removing duplicate information*

    API information available from http://dojotoolkit.org/api/ shouldn't be
    in the doc. Rather, the doc should link to this info via code like:

    .. api-inline :: dijit.Dialog

    The API doc admittedly currently has some problems (in particular,
    (non-function) attributes aren't showing up?) but that will be fixed
    eventually.


    *5. Splitting long lines*

    Now that we are using "normal" editors for editing the doc, it's easier
    to edit pages if the lines are wrapped (at around maybe 120 characters or
    less). I'm sure there are many ways to do this; I ran the following regex
    repeatedly, until it had no more matches:

    converting: ^([a-zA-Z].*[\.\?\!]) +([a-zA-Z])

    into: $1\n$2
    It's not perfect because it doesn't affect lists or tables correctly, but
    it's a start. The results should be checked over before they are checked
    in.


    *6. check that pragmas like .. js :: are right*

    Check with the examples is that they use the right pragmas. It should
    be

    .. js ::

    for javascript code, without a surrounding <script> tag.

    .. css ::

    for CSS code, without a surrounding <style> tag

    and

    .. html ::

    for anything with tags like <div>, even if inside that tag it has
    javascript, ex: <script type="dojo/method" ...>


    I'm sure there's something else that I'll think of right after sending
    this message, but anyway that's a start.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111226/c6b85ec4/attachment.htm
  • Kitson Kelly at Jan 13, 2012 at 5:00 am
    Is there anyway we can easily get commit permission to just the docs? Or
    is the only way, forking and pull requests? I ask, because it is odd that
    I can directly edit through the front end interface, but I have to fork and
    pull if I want to edit offline and can't just push my changes directly.
    On 23 December 2011 01:50, Bill Keese wrote:

    The docs continue to be editable through livedocs.dojotoolkit.org, but
    also they can now also be edited directly, see instructions which (for the
    time being) are in http://oksoclap.com/22eEx9Hh4Q. Committers can
    directly check in the changes, and (theoretically) non-committers can clone
    the docs repository to their own github account, make changes, and then
    send a pull request.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120113/797082d4/attachment.htm
  • Peter Higgins at Jan 13, 2012 at 8:40 am
    There is, via github acls ? I have a "doc team" group under the Dojo organization with w+ only on the dojo/docs repo. Drop me a line off list and we can get you added there.

    Additionally, once you are setup with w+ perms, you can fork rstwiki itself, and run a livedocs locally so you can test offline changes before committing.

    ~phiggins

    On Jan 13, 2012, at 5:00 AM, Kitson Kelly wrote:

    Is there anyway we can easily get commit permission to just the docs? Or is the only way, forking and pull requests? I ask, because it is odd that I can directly edit through the front end interface, but I have to fork and pull if I want to edit offline and can't just push my changes directly.

    On 23 December 2011 01:50, Bill Keese wrote:
    The docs continue to be editable through livedocs.dojotoolkit.org, but also they can now also be edited directly, see instructions which (for the time being) are in http://oksoclap.com/22eEx9Hh4Q. Committers can directly check in the changes, and (theoretically) non-committers can clone the docs repository to their own github account, make changes, and then send a pull request.

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120113/b81ff2c3/attachment.htm
  • Kitson Kelly at Jan 14, 2012 at 3:12 am
    Just a tip, for anyone using Eclipse to do RST editing (or wanting to).
    There is a plug-in available on the Eclipse Marketplace called ReST
    Editor<http://marketplace.eclipse.org/content/rest-editor>.
    It allows you to setup word wrap (I have it set to Hard 120). The plugin
    is generally ok, in that it at least gives you the ability your ReST Markup
    coloured and does some level of spell checking on your documents.

    The good thing is it at least understands what should/could be wrapped
    safely and what can't.
    On 23 December 2011 01:50, Bill Keese wrote:


    *5. Splitting long lines*

    Now that we are using "normal" editors for editing the doc, it's easier to
    edit pages if the lines are wrapped (at around maybe 120 characters or
    less). I'm sure there are many ways to do this; I ran the following regex
    repeatedly, until it had no more matches:

    converting: ^([a-zA-Z].*[\.\?\!]) +([a-zA-Z])

    into: $1\n$2
    It's not perfect because it doesn't affect lists or tables correctly, but
    it's a start. The results should be checked over before they are checked
    in.

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120114/a7e6d5b4/attachment.htm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedDec 22, '11 at 8:50p
activeJan 14, '12 at 3:12a
posts8
users4
websitedojotoolkit.org

People

Translate

site design / logo © 2022 Grokbase