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

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

> 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
>> 
>> 
>