- From: Steven Rowat <steven_rowat@sunshine.net>
- Date: Thu, 1 Dec 2016 12:50:23 -0800
- To: "Stone, Matt" <matt.stone@pearson.com>, Gregg Kellogg <gregg@greggkellogg.net>
- Cc: Credentials Community Group <public-credentials@w3.org>
On 12/1/16 12:06 PM, Stone, Matt wrote: > i ran across this link this morning - it was good for terminology and > process: https://guides.github.com/introduction/flow/ > <https://www.google.com/url?q=https%3A%2F%2Fguides.github.com%2Fintroduction%2Fflow%2F&sa=D&sntz=1&usg=AFQjCNHetLzbysCk17TS8EseLrTVNu0Zlw> > Great overview, thank you very much. That was planned for people like me I think. :-) Now I can go back and look at what Gregg just posted and see if I can begin to understand it. LOL Steven > > > ===== > Matt Stone > 501-291-1599 > > > On Thu, Dec 1, 2016 at 1:03 PM, Gregg Kellogg <gregg@greggkellogg.net > <mailto:gregg@greggkellogg.net>> wrote: > > Something else that might help: on the GitHub page for a specific > file > (e.g., https://github.com/opencreds/vc-data-model/blob/gh-pages/CONTRIBUTING.md > <https://github.com/opencreds/vc-data-model/blob/gh-pages/CONTRIBUTING.md>), > if you have edit rights on the repository (if you don’t you can > fork the repository using the button in the upper right). Note on > the file there is an edit tool (a pencil icon) near “Raw”, > “Blame”, and “History”. If you click this, you can edit the file > in it’s source form. At the bottom, after your commit changes, you > have the option to “Commit directly to the gh-pages branch” (which > should _never_ be done) or “Create a new branch for this commit > and start a pull request”. Select the second option, and when you > commit the changes, it will automatically create a pull request > for someone to choose to integrate, or use as the basis for > discussion. > > If you do it in a forked repository, you may need to select where > the pull request will be made, to ensure it goes back to the > original repository. > > There remains an issue about keeping your fork up to date, but you > can always delete the fork after your request is accepted and merged. > > Gregg Kellogg > gregg@greggkellogg.net <mailto:gregg@greggkellogg.net> > >> On Dec 1, 2016, at 10:50 AM, Steven Rowat >> <steven_rowat@sunshine.net <mailto:steven_rowat@sunshine.net>> >> wrote: >> >> On 12/1/16 8:20 AM, Daniel Burnett wrote: >>> keep your local copy synced with what's on the server. Again, >>> none of >>> this is super difficult, but there are definitely more steps >>> involved >>> than for creating issues, and that's because pull requests >>> assume you >>> are actually editing your own local copy of the files (meaning not >>> just using a web tool as with GitHub issue creation). >> >> Aha! So that's where the mysterious branched document resides: >> *on my machine*! (Strikes his head with his palm). >> >> Thank you, that's exactly the kind of basic thing that an >> experienced coder would understand from seeing the Github >> instructions, and which I didn't. >> >>> I should have time to send something next week and, as I said >>> on the >>> call, am offering to do a mini-review of those steps week after >>> next >>> when I can next be on the call. >> >> Good, I look forward to it. >> >> And/or, if anybody knows of an existing tutorial link, "Github >> Pull requests for Dummies", please don't hesitate to post it. :-) >> >> In this vein, there's an interesting new effort at MIT that has >> created "Gitless", which runs on top of Git (though not at >> GhitHub yet I assume), and apparently removes some of the (less >> necessary) staging complications. >> >> http://news.mit.edu/2016/gitless-making-it-easier-to-collaborate-on-code-1025 >> <http://news.mit.edu/2016/gitless-making-it-easier-to-collaborate-on-code-1025> >> >> Steven >> >> >>> >>> -- dan >>> >>> >>> On Thu, Dec 1, 2016 at 10:46 AM, Steven Rowat >>> <steven_rowat@sunshine.net <mailto:steven_rowat@sunshine.net> >>> <mailto:steven_rowat@sunshine.net >>> <mailto:steven_rowat@sunshine.net>>> wrote: >>> >>> On 11/29/16 9:32 AM, msporny@digitalbazaar.com >>> <mailto:msporny@digitalbazaar.com> >>> <mailto:msporny@digitalbazaar.com >>> <mailto:msporny@digitalbazaar.com>> wrote: >>> >>> Manu Sporny: Issues in the issues tracker, as you find >>> them in >>> the spec, please write them in the issue tracker or they >>> will get >>> ... >>> >>> Dan Burnett: About Pull Requests - PRs are the way to >>> propose >>> specific changes to the document. You edit the >>> document and push >>> that edit up such that it can be reviewed, including >>> by the >>> editors, once that's done it can be applied to the >>> document. The >>> editors will encourage people to do that. I know some >>> people >>> haven't done that before. >>> >>> >>> I'll report that I've just read the current data model and use >>> cases for VC, and I added: >>> 4 Github issues for the data model >>> 13 Github issues for the use cases. >>> >>> I was brand new to Github so I'll report for others like myself >>> that it was painless, even pleasant. :-) . All it took was >>> another new password. >>> >>> About half my issues are minor grammatical issues, which I think >>> should be done at some point but aren't urgent. Several though, >>> I've taken issue with meaningful text, so I hope that people >>> will >>> look at them and comment (yay or nay or changes). >>> >>> In terms of Pull Requests as Dan spoke of: >>> It certainly occurred to me that it would be simple if I could >>> make the minor changes on a branch of the document myself, >>> because >>> I doubt if anyone's going to complain if I change "knwoing" to >>> "knowing" (a real example). >>> >>> But, I looked at Github's explanation of the Pull process, and >>> backed off. Yep, that's for coders. There are about ten >>> different >>> 'but if A happens, do B' statements, on the directions page, >>> some >>> of which use words whose meanings I don't (yet) know. >>> >>> What I'm hoping for is if someone can give directions for the >>> simplest Pulls that you're looking for, just like the VC Minutes >>> gave for the Issues, which were beautifully described. >>> Something like: >>> >>> To Do a Pull: >>> 1. Go to X Github page. >>> 2. Punch Button Y. >>> 3. Edit the document, using standard cut and paste. >>> 4. Punch Button Z. >>> >>> :-) >>> >>> Steven Rowat >>> >>> >> > >
Received on Thursday, 1 December 2016 20:50:59 UTC