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

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

Received on Thursday, 1 December 2016 18:51:02 UTC