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

Steven,

Yes, I'm thinking about how best to explain that.  Converting local edits
to a Pull Request is not too hard.  What is trickier is a) getting things
set up so you can do that, and b) making it easy to 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).

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.

-- dan


On Thu, Dec 1, 2016 at 10:46 AM, Steven Rowat <steven_rowat@sunshine.net>
wrote:

> On 11/29/16 9:32 AM, 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
>
>