W3C home > Mailing lists > Public > public-credentials@w3.org > December 2016

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

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>
Message-ID: <75a741e7-e124-3acb-6ca9-30a9e74fb791@sunshine.net>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:33 UTC