implement v8_util.getHiddenValue/setHiddenValue

[marcoscaceres]

LGTM.

@mykmelez, can we set up a workflow just to signal if things are ready for review? I'll generally look at all PRs, but maybe just "@ username r?" for review. That will can also signal if merging is ok after review.

[mykmelez]

@mykmelez, can we set up a workflow just to signal if things are ready for review? I'll generally look at all PRs, but maybe just "@ username r?" for review. That will can also signal if merging is ok after review.

Good idea! How about (riffing off of flows I've used in other GitHub-centric projects):

• PRs are generally assumed to be ready for review, and mergable by any contributor with write privileges, because most of the time a branch is ready by the time you request a pull on it, and multiple contributors are qualified to review it.
• To request a pull for a branch that isn't yet ready (to get early feedback), label it WIP (and then remove that label once it's ready).
• If you want a particular person to review/merge a PR, assign the PR to that person (analogous to assigning an issue to the person resolving it).
• If you want to be the reviewer/merger on an unassigned PR, assign yourself to it (analogous to assigning an issue to yourself if you want to be the person to resolve it).

(Then, if we find ourselves creating more WIPs than ready branches, we can flip the bit on which kinds of PRs need a label.)

[marcoscaceres]

On 19 Apr 2016, at 6:49 PM, Myk Melez notifications@github.com wrote:

@mykmelez, can we set up a workflow just to signal if things are ready for review? I'll generally look at all PRs, but maybe just "@ username r?" for review. That will can also signal if merging is ok after review.

Good idea! How about (riffing off of flows I've used in other GitHub-centric projects):

PRs are generally assumed to be ready for review, and mergable by any contributor with write privileges, because most of the time a branch is ready by the time you request a pull on it, and multiple contributors are qualified to review it. To request a pull for a branch that isn't yet ready (to get early feedback), label it WIP (and then remove that label once it's ready). If you want a particular person to review/merge a PR, assign the PR to that person (analogous to assigning an issue to the person resolving it). If you want to be the reviewer/merger on an unassigned PR, assign yourself to it (analogous to assigning an issue to yourself if you want to be the person to resolve it). (Then, if we find ourselves creating more WIPs than ready branches, we can flip the bit on which kinds of PRs need a label.)

The above sounds great! Thanks for clarifying.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub