Temperature check: preferred editing workflows?

[beep]

An excellent workflow suggestion was raised by @marcoscaceres on #64:

Two options: keep iterating and using the Previews at the top of this pull request to share and review the changes, or merge early/often and iterate.

I'm personally a fan of the former (keep hacking on a single PR), but the other way works fine too.

Generally, most of us in Slack (reminder: you can join us there!) default to the “merge PRs frequently, and iterate” workflow on collaborative projects. But given that (so far) our PRs have been opening at a fairly low volume, I can see the benefits of really honing a PR before merge.

This issue isn’t a blocker, and may not directly impact our workflow. But I am curious to know if anyone has any thoughts on the two models. Any preferences out there?

[tomhodgins]

Marcos knows how to get this sort of work done, so I trust his workflow if it's proven itself in the past. I'm a little new to on-Github collaboration with discussion inside of PRs like this—I'm used to using Git on other services where the the collaboration and discussion happens either before a merge, or after, but I'm not as familiar with all that can be done on Github during a PR (comments, in-line comments, reviews, checkmarks, etc.)

From the perspective of editing it doesn't really make too much of a difference to me, but I wonder which way easier for contributors - they'll be the ones it would impact most!

If you are somebody who would consider submitting ideas to this repository, which way (many PRs with rougher edits, or fewer PRs with more polish) would encourage you to contribute and make the tweaks and changes necessary to get this document into shape?

[marcoscaceres]

@tomhodgins

but I'm not as familiar with all that can be done on Github during a PR (comments, in-line comments, reviews, checkmarks, etc.)

This is probably GitHub's most powerful feature. The ability for multiple people to go in and comment inline is extremely useful... specially because as comments get addressed by new commits, Github makes addressed comments automatically disappear.

In a sense, the comments work as a TODO list of things to fix... and once there is no comment left, then the Pull Request is merged.

From the perspective of editing it doesn't really make too much of a difference to me, but I wonder which way easier for contributors - they'll be the ones it would impact most!

Agree. Whatever works best for you all.

If you are somebody who would consider submitting ideas to this repository, which way (many PRs with rougher edits, or fewer PRs with more polish) would encourage you to contribute and make the tweaks and changes necessary to get this document into shape?

I'd suggest you avoid these hypotheticals. Adapt your process to suit the community as you go... if you find a lot of random people start showing up fixing typos, etc. then move to a faster release model.

This is why #59 is kinda important. In other projects, we've had a lot of problems in the past of people editing the generated document - and then they get disappointed because we can't accept their fixes and they have to do the work again.

[eeeps]

What @tomhodgins said! (I'm new to all of these GitHub processes, trust Marcos, and also want to do everything I can to lower the [big, scary] bar to contribution).

[marcoscaceres]

If you want to see what it looks like in practice, see, for example: https://github.com/w3c/payment-request/pull/666

There, a bunch of us reach attempt to reach consensus. I had to fix a bunch of things, answer a bunch of questions, etc. and then finally got some ticks. The PR has "cooked" for a more than a month now, but lots of folks had input, and lots of things got changed to reach it's current state.

It's basically the same as we've seen in #64, so you are all doing great working together! ❤️

[andykirk]

I’m not used to collaborating like this either, but I’m happy with either approach, and adapting as things progress.

[beep]

Awesome—thanks, all! Since #64 is working out so well, let’s continue with that model for now. (We can definitely revisit that if it’s not working, too!)

Thanks again for weighing in, and thanks to @marcoscaceres for suggesting a different approach. Y’all rock.