Well the 3rd possibility and the preferred way (short of you getting commit rights) so you get proper credit/blame is for you to prepare a git patch and e-mail it to me.
To answer Anders question you always edit the doc in the current branch if that component is in that branch. If the component is in master only then edit masters docs. Commits are pushed up from branches not cherry picked from master. Right now we are left with a huge mess in the documents with most of the translated docs left untranslated. The ones not translated need to be removed so updates are kept current without having to muck about looking through other documents to try and keep them up to date. I'm pretty sure I have all the links in the translated docs pointing to the English docs so the _de and _pl docs need to be deleted along with most of the _es docs. I'll try and have that done soon. BTY Kent, that is quite a write up about the 2.5 document chain. JT On 6/5/2013 12:23 AM, Kent A. Reed wrote: > Ok, so Michael has thrown down the gauntlet: "Now please stop the damn > 'thank you' thing, and contribute something." > > Circumstances prevent me from contributing much in the way of code but > y'all know I have a passion for decent documentation. I have made a > number of contributions to the Wiki and to the distributed LinuxCNC > documentation. > > The process I used last year to contribute to the docs was horribly > inefficient. I would first find problems, then document them as to > source file, line, and the change to be made. Then I'd fire off emails > to John Thornton who would fire up his trusty editor and, file by file, > line by line, first locate what I was talking about, and then make the > corrections he agreed with (which he mostly did; thanks, John). > > Frankly, I'd rather just edit the document source files and be done with > it. It's something I can do at odd moments during the day as I see > problems in the pdf/html results. > > I see two possibilities for doing this in an organized way: > > 1) create my own public git repository, edit and post files to it after > pulling from the central repository, and announce their availability to > y'all. It would then be up to 'someone' to pull them and merge them in > the central repository. > > or > > 2) get push privilege to the central repository. It would be super if > git allowed for restriction of push privilege to the ./docs subset, > since that's all I need/want, but I'm not aware that it does. > > And the answer is...? > > Regards, > Kent > > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
