Re: Verifiable Claims Telecon Minutes for 2016-11-29

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>



=====
Matt Stone
501-291-1599


On Thu, Dec 1, 2016 at 1:03 PM, Gregg Kellogg <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), 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
>
> On Dec 1, 2016, at 10:50 AM, Steven Rowat <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
>
> Steven
>
>
>
> -- dan
>
>
> On Thu, Dec 1, 2016 at 10:46 AM, Steven Rowat
> <steven_rowat@sunshine.net <mailto:steven_rowat@sunshine.net>> wrote:
>
>    On 11/29/16 9:32 AM, 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
>
>
>
>
>