doc: charter the Release working group #223

mhdawson · 2017-06-01T19:40:45Z

In the last LTS meeting we discussed chartering the LTS workgroup as a merger of the current LTS and Release teams.

This is a first cut at the governance doc for that.

If it move forward, I'll take content from the mandate section in the README.md to add to https://github.com/nodejs/CTC/blob/master/WORKING_GROUPS.md

Needs input from the members of the release team who are not part of the LTS group as this may be the first time the concept has been been suggested to them.

part 1 - governance and docs for repo

mhdawson · 2017-06-01T19:41:35Z

@nodejs/LTS and @cjihrig, @evanlucas, @italoacasas.

mhdawson · 2017-06-01T19:49:01Z

One more comment, we may want to rename the repo from LTS to Release and LTS but we can decide on that after we reach consensus that chartering in this form is the way to go.

richardlau · 2017-06-02T00:12:47Z

GOVERNANCE.md

@@ -0,0 +1,125 @@
+# Release and LTS Working Group
+
+The nodejs Release and LTS project is governed by a Working Group (WG) that


richardlau · 2017-06-02T00:13:52Z

GOVERNANCE.md

+
+## Collaborators
+
+The benchmarking GitHub repository is maintained by the WG and additional


benchmarking?

richardlau · 2017-06-02T00:17:09Z

GOVERNANCE.md

+    Contribution policy
+    GitHub repository hosting
+    Conduct guidelines
+    Maintaining the list of additional Collaborators


Should these be a list?

Not sure this list makes sense in the context of this WG.

richardlau · 2017-06-02T00:18:50Z

@nodejs/lts

hutson · 2017-06-02T03:06:27Z

GOVERNANCE.md

+
+## WG Meetings
+
+The WG meets weekly on a Google Hangout On Air. A designated moderator


I believe the current meeting frequency, at least for the LTS WG, is once every three weeks. I'm not sure about the Release team specifically.

the release team does not meet at all.

hutson · 2017-06-02T03:08:07Z

GOVERNANCE.md

+## WG Meetings
+
+The WG meets weekly on a Google Hangout On Air. A designated moderator
+approved by the WG runs the meeting. Each meeting should be


Is there a process for deciding the moderator?

we would need to define one

hutson · 2017-06-02T03:09:45Z

README.md

@@ -1,6 +1,6 @@
-# Node.js Long-term Support Working Group
+# Node.js Release and Long-term Support Working Group


It feels like maintaining the LTS releases really falls under the greater umbrella of maintaining releases in general, so the WG could just be called Release WG.

hutson · 2017-06-02T03:10:19Z

README.md


-# LTS schedule<sup>1</sup>
+## LTS schedule<sup>1</sup>


Since this table contains non-LTS releases, though not fully documented, how about Release Schedule?

Or perhaps at this point a general Release table would be in order since this WG would now be responsible for all releases?

jasnell · 2017-06-02T03:38:00Z

GOVERNANCE.md

+# Release and LTS Working Group
+
+The nodejs Release and LTS project is governed by a Working Group (WG) that
+is responsible for high-level guidance of the project.


The Node.js Release and Support Working Group maintains oversight over the Node.js Release and Long Term Support Teams, and manages the release and long term support schedule and policies for all Node.js releases.

The Release and LTS stuff is not a "project"

jasnell · 2017-06-02T03:38:21Z

GOVERNANCE.md

+    Contribution policy
+    GitHub repository hosting
+    Conduct guidelines
+    Maintaining the list of additional Collaborators


Not sure this list makes sense in the context of this WG.

jasnell · 2017-06-02T03:39:41Z

README.md

-# LTS Plan
+## Mandate
+
+The Release and LTS working group's purpose is:


The WG should be made up of two distinct teams: The Release Team and the LTS/Backporting Team. Everything here should be cast in terms of splitting the responsibilities of the WG between those two teams

jasnell · 2017-06-02T03:40:40Z

GOVERNANCE.md

+
+## WG Meetings
+
+The WG meets weekly on a Google Hangout On Air. A designated moderator


There's never been a reason for the Release team to have a meeting and it's not clear there would need to be a reason after forming this WG. We should factor that in. We don't want to force process where none is needed.

jasnell · 2017-06-02T03:41:12Z

README.md

@@ -26,7 +26,42 @@
 The LTS Schedule is available also as a [JSON][] file or [ICal][]. There is
 also a live [Google Calendar][] that may be subscribed to.


This section doesn't really seem necessary here

jasnell · 2017-06-02T03:41:40Z

README.md

+
+* Release team
+* LTS team
+* Backporting team


The LTS team and Backporting team do not really need to be separate entities

I'm not sure I 100% agree with this. The backporting team has been trained on how to backport and has specific permissions. Not everyone who is part of the LTS working group has that

Currently the LTS responsibilities fall into two categories:

Determining the LTS release schedule

Deciding what goes into the LTS releases

The backporting team handles item 2. Both the release team and backporting teams can share responsibility for 1, meaning that we really only need two teams: backporting and release, who work together on the schedule.

jasnell · 2017-06-02T03:42:49Z

README.md

+collaborators from any of the Node.js working groups. 
+
+
+## LTS Plan


The LTS plan should be a separate document that is not part of the charter. That way the WG can change it when it needs without having to modify the charter.

this is the README.md for the repo. The charter the smaller section that defines its purpose and scope. Once that's agreed it will go into the doc in the CTC defining the WG's scope. We can chose to move the LTS plan out of the README.md for the repo but I don't think thats tied to chartering the WG.

jasnell · 2017-06-02T03:43:26Z

README.md


+* Colin Ihrig [@cjhrig](https://github.com/cjihrig)


I would split these into distinct lists, even if there is overlap

jasnell · 2017-06-05T15:32:36Z

FYI: We should make sure that this PR and nodejs/CTC#122 stay in sync.

mhdawson · 2017-06-06T22:01:16Z

I'm sure it will need more changes/editing but first cut to update to reflect discussion from last LTS meeting.
@nodejs/lts @nodejs/release

mhdawson · 2017-06-06T23:13:31Z

I just got home and checked my notes and seems that the what I called the release team to match the WG name should have been the lts team

+* Release team -> LTS team

+The LTS team manages the process/content of releases.

I'll fix that up tomorrow

mhdawson · 2017-06-07T15:59:55Z

pushed commit to fix up team names.

evanlucas · 2017-06-07T16:58:21Z

README.md

 * Sam Roberts [@sam-github](https://github.com/sam-github)

-Github team for LTS: https://github.com/orgs/nodejs/teams/lts
+### Releasers team


This seems to be missing Colin and myself? Not sure if that is intended or not?

Nope. My apologies, will fix up in next pass through. I messed that up willing splitting up the teams.

evanlucas · 2017-06-07T16:58:47Z

README.md

 * Gibson Fahnestock [@gibfahn](https://github.com/gibfahn)
-* James M Snell [@jasnell](https://github.com/jasnell)
-* Jeremiah Senkpiel [@Fishrock123](https://github.com/Fishrock123)
+* James M Snell [@jasnell](https://github.com/jasnell) 


was the extra whitespace meant to be added?

evanlucas

Would we rename the repository if this were to land?

evanlucas · 2017-06-07T16:59:14Z

README.md

-* James M Snell [@jasnell](https://github.com/jasnell)
-* Jeremiah Senkpiel [@Fishrock123](https://github.com/Fishrock123)
+* James M Snell [@jasnell](https://github.com/jasnell) 
+* Jeremiah Senkpiel [@Fishrock123](https://github.com/Fishrock123) 


This line appears to have extra whitespace as well

evanlucas · 2017-06-07T17:01:55Z

README.md

+build and sign releases.  **Additions to the releasers team must be approved
+by the CTC.**
+
+The Long Terms Support (LTS)  team manages the process/content of LTS  releases


s/Long Terms/Long-term/ ?

There also appears to be a few double whitespaces in this sentence.

evanlucas · 2017-06-07T17:02:56Z

README.md

@@ -23,10 +23,44 @@

 <p><img src="schedule.png" alt="LTS Schedule"/></p>

-The LTS Schedule is available also as a [JSON][] file or [ICal][]. There is
+The Release schedule is available also as a [JSON][] file or [ICal][]. There is


Does this mean that Current releases will have to follow a schedule as well?

I don't think we intended to enforce a schedule for Current releases, although there was some discussion in the LTS meeting that something like a 2 week interval might make sense.

evanlucas · 2017-06-07T17:04:23Z

GOVERNANCE.md

+
+* Release process and tools.
+* Content for all releases.
+* Schedule for all release.


s/release/releases/

evanlucas · 2017-06-07T17:05:26Z

GOVERNANCE.md

+The WG has final authority over Releases including:
+
+* Release process and tools.
+* Content for all releases.


Just to clarify, does this mean that even if the CTC were to vote on landing something in a release, this WG could override that?

I believe that using the standard delegation of responsibility from the CTC to the WG that is correct. As a final measure the CTC could dissolve the WG in order to take back responsibility if the WG is not acting in accordance with the CTC's vision.

Yep, generally we've always operated on the model that the person actually doing the release has the final say about what is included in the release. The CTC may decide to include something, but if the releaser finds an issue that would block the release, they should have the freedom to omit it until the issue is resolved.

This puts the Release Working Group above the CTC. If it is the Release WG that can decide what composes a release, they can decide (autonomously) to pull a semver-major commit they do not agree with from a semver-major release. In similar fashion, they can decide to put something in that is not present in nodejs/node.

All of this is very hypothetical, but hypothetical things happened before so I would like to avoid conflicts before they happen.

I do agree that the current model is the right model and they should be able to omit things, but this sentence is too broad.

How about:

Content for all releases, according to the contributions in nodejs/node and semver levels.

I hope it clarifies what I mean.

@mcollina that is the explicit intention, and true of all WGs (as I understand it). See @mhdawson 's comment at #223 (comment). The CTC delegates to the Release WG on the matter of what goes in releases. If its unhappy about what the WG does, it has power to dissolve the WG. If CTC members have strong feelings about what the Release WG should do... they should join the WG. In your example, if a commit is pulled because the WG doesn't agree with its content (as opposed to it not passing CI, not backporting clean, or some other reason involving the release process), the WG would be overstepping its bounds, and I assume the CTC would dissolve it.

Agreed on dissolving. However if we consider other WGs, this WG will have the responsibility to what is Node in the hand of our users, this is very different to most of the other WGs.

... the WG would be overstepping its bounds ...

Yes, exactly. I'm just pointing it out that those bounds are not written here. It might not be on this point, but a generic mention to them would be welcomed, maybe at the top.

Again, my understanding (but I can be wrong on this) is that it is the same as most WGs. Streams has final authority about what goes into readable_stream, for example. You've never done anything objectionable, so there has never been conflict, and no one expects there to be, but its the streams WG who decides on what happens with streams. Maybe the WG charters need to change to saying that anything they decide can be overruled by a vote of CTC without dissolving the WG?

I think that is already part of how things are set up if there is a conflict, now that I think about it. Good to know, thanks.

I am extra careful here, because this is the most critical activity of the Node.js process.

Agreed with the caution.

evanlucas · 2017-06-07T17:06:04Z

GOVERNANCE.md

+during the weekly WG meeting.
+
+**Note**: If you make a significant contribution and are not considered for
+commit-access log an issue or contact a WG member directly and it will


missing comma after commit-access?

evanlucas · 2017-06-07T17:07:34Z

GOVERNANCE.md

+
+Members of the `releasers` sub-team are not required to attend
+the WG meetings and maintain their WG membership simply by
+participating in the release process.


Is there a set time period for which a releaser must actively cut releases? If so, we should probably clarify that?

Added 'at least once a year' as a starting point for people to agree or suggest some alternative.

evanlucas · 2017-06-07T17:10:52Z

README.md

+* James M Snell [@jasnell](https://github.com/jasnell) (release team)
+* Myles Borins [@MylesBorins](https://github.com/MylesBorins) (release team)
+* Gibson Fahnestock [@gibfahn](https://github.com/gibfahn)
+* George Adams [George Adams](https://github.com/gdams)


This section is mixed, some have the GitHub username, others have the name. I would probably make this consistent

Do you means Myles, looks like his current github id is MylesBorrins.

I meant that starting with George, all of the CITGM members have their name as the link, not their GitHub username. So, this line specifically should probably be * George Adams [@gdams](https://github.com/gdams) and the ones below should follow that same format.

mhdawson · 2017-06-07T17:55:07Z

Pushed change to address latest comment.

richardlau · 2017-06-09T08:39:23Z

README.md

+* Colin Ihrig [@cjhrig](https://github.com/cjihrig)
+* Evan Lucas [@evanlucas](https://github.com/evanlucas)
+* Italo A. Casas [@italoacasas](https://github.com/italoacasas)
+* James M Snell [@jasnell](https://github.com/jasnell) (release team)


(release team) has been left behind after breaking the list into teams.

richardlau · 2017-06-09T08:53:11Z

GOVERNANCE.md refers to the project README.md for both list of WG members and Collaborators but it's not clear with the current list of team members in the README.md whether they are WG members, Collaborators or both.

richardlau · 2017-06-09T08:58:05Z

Also since it looks like the CITGM team is being brought under this WG, cc @nodejs/citgm.

mhdawson · 2017-06-19T17:29:41Z

Pushed commit to address all comments: @jasnell @MylesBorins @richardlau @hbetts @evanlucas

Fishrock123

seems fine overall, not sure I have much opinion beyond that atm

Fishrock123 · 2017-08-02T23:05:11Z

GOVERNANCE.md

+* Content for all releases.
+* Schedule for all releases.
+* Contribution policy for the Release repository.
+* Conduct guidelines for the Working group.


Not sure this is worth it? Seems to be easier to have conduct just CTC guided?

Fishrock123 · 2017-08-02T23:05:43Z

GOVERNANCE.md

+Collaborators who are added by the WG on an ongoing basis.
+
+Individuals making significant and valuable contributions are made
+Collaborators and given commit-access to the project. These individuals


What is "the project" here?

It is the LTS repo to be remained to the Release repo. I'll change from project to Release repository.

Fishrock123 · 2017-08-02T23:06:29Z

GOVERNANCE.md

+during the WG meeting.
+
+**Note**: If you make a significant contribution and are not considered for
+commit access, log an issue or contact a WG member directly and it will


I am not sure this is how the release group should work, was this copied verbatim from the core contribution policy?

Seems like a similar problem that other WGs have—how do you define contributions and how should that be measured to determine membership? Many of them are just "you join enough meetings, hang around and offer to lend a hand where needed and you can join" (Build is a bit like this), or simply just "want to join? sure!". Have we solved this wording anywhere else in our WGs that we can reapply here because the core rules don't seem to apply.

This related to the Release repo where issues/minutes/etc are captured not related to releases themselves so I think it still applies.

We have the same wording in the benchmarking WG, the post-mortem WG, Intl, the now inactive test WG used similar wording.

Not a WG but one which is different is the community committee, which uses the participation rules. Basically get involved and once you meet the participation rules you will be added. The rules are:

In the case where an individual CC member -- within any three month period -- attends fewer than 25% of the regularly scheduled meetings, does not participate in CC discussions, and does not participate in CC votes, the member shall be automatically removed from the CC. The member may be invited to continue attending CC meetings as an observer.

In my opinion the existing wording is pretty generic in that "significant" can be determined by the WG and I don't think there have been problems with people asking to be added/getting refused.

So I'm open to a better suggestion if someone has one but I'm also fine with what we have already.

mhdawson · 2017-08-16T23:08:19Z

@Trott does this need a formal vote ? I see sign off by 5 CTC members (counting myself) and no objections.

rvagg · 2017-08-14T06:19:06Z

GOVERNANCE.md

+
+## WG Meetings
+
+The WG meets every 3 weeks on a Google Hangout On Air. One of the


might be best to leave the specifics of the schedule out of the governance docs and make it "regularly" or "as the WG determines appropriate" so it doesn't have to be updated when the WG decides to make it less or more frequent.

Makes sense to me, updated.

rvagg · 2017-08-14T06:22:41Z

GOVERNANCE.md

+during the WG meeting.
+
+**Note**: If you make a significant contribution and are not considered for
+commit access, log an issue or contact a WG member directly and it will


Seems like a similar problem that other WGs have—how do you define contributions and how should that be measured to determine membership? Many of them are just "you join enough meetings, hang around and offer to lend a hand where needed and you can join" (Build is a bit like this), or simply just "want to join? sure!". Have we solved this wording anywhere else in our WGs that we can reapply here because the core rules don't seem to apply.

rvagg · 2017-08-17T06:51:53Z

Sorry, I did make comments for review but didn't complete it to push them as requesting changes so I guess they didn't show up. The "making significant contributions" thing is a problem, not a blocker but my preference would be to sort out how one qualifies for membership in a WG such as this ASAP.

mhdawson · 2017-08-17T13:56:38Z

To make sure they are seen: on the from of qualifications for WG membership:

We have the same wording in the benchmarking WG, the post-mortem WG, Intl, the now inactive test WG used similar wording.

Not a WG but one which is different is the community committee, which uses the participation rules. Basically get involved and once you meet the participation rules you will be added. The rules are:

In the case where an individual CC member -- within any three month period -- attends fewer than 25% of the regularly scheduled meetings, does not participate in CC discussions, and does not participate in CC votes, the member shall be automatically removed from the CC. The member may be invited to continue attending CC meetings as an observer.
In my opinion the existing wording is pretty generic in that "significant" can be determined by the WG and I don't think there have been problems with people asking to be added/getting refused.

So I'm open to a better suggestion if someone has one but I'm also fine with what we have already.

mhdawson · 2017-08-17T14:01:35Z

Addressed comments minus new wording for qualifications for WG membership. I'd prefer if we handled that in a follow on PR.

Trott · 2017-08-17T18:45:39Z

@Trott does this need a formal vote ? I see sign off by 5 CTC members (counting myself) and no objections.

@mhdawson The TSC has a process for chartering workgroups but as far as I know the CTC does not have a documented process. (Correction welcome, of course.)

So this (IMO) should be treated like any other CTC decision: If CTC folks have approved, no one has objected, and a sufficient period of time has passed, then we're all good.

Since you did just push some changes 5 hours ago, it would probably be considerate to @-mention CTC and say something like "I've made some changes to address all outstanding nits. I think this is ready to land. PTAL. I'll land this after XX:XX UTC time on SuchAndSuchDay if there are no objections."

IMO we should avoid voting unless explicitly required by our governance docs and/or all other options have been exhausted. So I'm happy to see this pass through consensus and not have to go to a vote.

Trott · 2017-08-17T19:58:25Z

@mhdawson The TSC has a process for chartering workgroups but as far as I know the CTC does not have a documented process. (Correction welcome, of course.)

Looks like I'm kinda sorta wrong in that the main repo WORKING_GROUPS.md links to the TSC version saying the process is the same. But it doesn't require a vote explicitly either. So I think we're good.

If anyone disagrees and wants to make this a formal vote, I'll defer to that. But IMO we don't need to do that.

mhdawson · 2017-08-17T20:44:51Z

@Trott thanks. I'll wait until tomorrow to see if @Fishrock123 or @rvagg have objections to landing before we close on the discussion about qualifications, otherwise I'll follow the suggestion you made for notification/warning.

mhdawson · 2017-08-18T14:59:14Z

@nodejs/ctc "I've made some changes to address all outstanding nits. I think this is ready to land. PTAL. I'll land this after 12 EST on Tuesday Aug 22nd if there are no objections."

part 1 - governance and docs for repo PR-URL: #223 Fixes: #48 Reviewed-By: Sam Roberts <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: MichaëZasso <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]> Reviewed-By: Myles Borins <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]> Reviewed-By: Bartosz Sosnowski <[email protected]> Reviewed-By: Rod Vagg <[email protected]>

mhdawson · 2017-08-24T21:43:44Z

Landed as 9df8393

Trott · 2017-08-24T21:59:59Z

Don't forget to update the website Working Groups page as necessary! @nodejs/website

Was recently chartered in as per nodejs/Release#223

Was recently chartered in as per nodejs/Release#223 PR-URL: #167 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>

part 1 - governance and docs for repo PR-URL: nodejs#223 Fixes: nodejs#48 Reviewed-By: Sam Roberts <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: MichaëZasso <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]> Reviewed-By: Myles Borins <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]> Reviewed-By: Bartosz Sosnowski <[email protected]> Reviewed-By: Rod Vagg <[email protected]>

doc: charter the Release and LTS working group

052ba9f

part 1 - governance and docs for repo

mhdawson self-assigned this Jun 1, 2017

squash: fix nit

47668c7

richardlau reviewed Jun 2, 2017

View reviewed changes

hutson reviewed Jun 2, 2017

View reviewed changes

jasnell previously requested changes Jun 2, 2017

View reviewed changes

mhdawson mentioned this pull request Jun 5, 2017

Chartering the Release Team as a Working Group nodejs/CTC#123

Closed

squash: update based on discussion in last LTS meeting

624753d

mhdawson mentioned this pull request Jun 7, 2017

meta: charter the LTS Working Group nodejs/CTC#122

Closed

squash: fix up naming of teams

cf51ecc

mhdawson changed the title ~~doc: charter the Release and LTS working group~~ doc: charter the Release working group Jun 7, 2017

squash: make all teams separate lists

ff49030

evanlucas reviewed Jun 7, 2017

View reviewed changes

squash: address next comments

5ec8727

richardlau reviewed Jun 9, 2017

View reviewed changes

gibfahn mentioned this pull request Jun 14, 2017

Github Subteams nodejs/node#13675

Closed

squash: address next set of comments

245b46b

Fishrock123 approved these changes Aug 8, 2017

View reviewed changes

Trott mentioned this pull request Aug 13, 2017

Node.js Foundation Core Technical Committee (CTC) Meeting 2017-08-16 nodejs/CTC#162

Closed

0610919566 approved these changes Aug 14, 2017

View reviewed changes

rvagg reviewed Aug 17, 2017

View reviewed changes

squash: address comments

3e0022a

bzoz approved these changes Aug 19, 2017

View reviewed changes

rvagg approved these changes Aug 20, 2017

View reviewed changes

squash: address comments

2a6c46a

mhdawson closed this Aug 24, 2017

mhdawson mentioned this pull request Aug 24, 2017

Rename the repo to Release #242

Closed

mhdawson added a commit to mhdawson/CTC that referenced this pull request Aug 24, 2017

meta: add release working group

ad5c022

Was recently chartered in as per nodejs/Release#223

mhdawson mentioned this pull request Aug 24, 2017

meta: add release working group nodejs/CTC#167

Closed

Trott removed the ctc-review label Aug 27, 2017

gibfahn mentioned this pull request Mar 6, 2018

Status of GitHub LTS team nodejs/admin#84

Closed

Trott mentioned this pull request Jan 29, 2019

doc: remove outdated COLLABORATOR_GUIDE sentence about breaking changes nodejs/node#25780

Closed

3 tasks

MylesBorins mentioned this pull request Jan 3, 2020

Web Frameworks Team nodejs/admin#459

Closed

		@@ -0,0 +1,125 @@
		# Release and LTS Working Group

		The nodejs Release and LTS project is governed by a Working Group (WG) that


		## Collaborators

		The benchmarking GitHub repository is maintained by the WG and additional


		## WG Meetings

		The WG meets weekly on a Google Hangout On Air. A designated moderator

		@@ -1,6 +1,6 @@
		# Node.js Long-term Support Working Group
		# Node.js Release and Long-term Support Working Group

		@@ -26,7 +26,42 @@
		The LTS Schedule is available also as a [JSON][] file or [ICal][]. There is
		also a live [Google Calendar][] that may be subscribed to.

		collaborators from any of the Node.js working groups.


		## LTS Plan


		## WG Meetings

		The WG meets every 3 weeks on a Google Hangout On Air. One of the

doc: charter the Release working group #223

doc: charter the Release working group #223

Conversation

mhdawson commented Jun 1, 2017 • edited Loading

mhdawson commented Jun 1, 2017

mhdawson commented Jun 1, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

richardlau commented Jun 2, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jasnell commented Jun 5, 2017

mhdawson commented Jun 6, 2017

mhdawson commented Jun 6, 2017 • edited Loading

mhdawson commented Jun 7, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

evanlucas left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mhdawson commented Jun 7, 2017

Choose a reason for hiding this comment

richardlau commented Jun 9, 2017

richardlau commented Jun 9, 2017

mhdawson commented Jun 19, 2017

Fishrock123 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mhdawson commented Aug 16, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rvagg commented Aug 17, 2017

mhdawson commented Aug 17, 2017

mhdawson commented Aug 17, 2017

Trott commented Aug 17, 2017

mhdawson commented Jun 1, 2017 •

edited

Loading

mhdawson commented Jun 1, 2017 •

edited

Loading

mhdawson commented Jun 6, 2017 •

edited

Loading