crtlaltdel

We have a #bugs slack channel. It is a dumping ground for issues, or potential issues, and doesn’t always (or often really) lead to action like opening a bug ticket in our tracker. Often the context gets tangled up in other conversations in the same channel.

Do you have a channel like this? How do you manage it’s use? Does it make more sense to remove it and force all bug-related conversation to occur via the ticketing system?

I've encountered several startups that embrace "office dogs" in the course of my career. Most of them its an occasional event, usually when the owner has trouble with pet sitting or something. A couple, however, have a constant presence of dogs. Multiple dogs. They bark, "play fight" and attempt to get some person (any person) to pay attention to them. None of them are scary or overly aggressive.

This is not a large space, though hardly a "garage" sized office.

I like dogs.

This pack of dogs is making me hate this office. It has gotten to the point where even the most typical, innocuous "dog behavior" in the office irritates me. It ruins my flow and engenders a modest resentment towards their owners.

I am at a loss to address this. The company is small enough that the non-bring-dog-to-work folks are a minority, and all of the senior leadership team bring theirs. If this was occasional, it wouldn't bother me...but it is just about every-single-day.

Every.

Single.

Day.

I'd not consider bringing my small children to the office every day only to let them roam around bothering people and squabbling over a toy...is it too much to expect the same of "pet parents" and their "fur babies"?

I have encountered a number of situations where a majority of code review comments for my team end up being (slightly pedantic) style/form related. Some times its a matter of naming conventions, others its something like `prefer const over let if no reassignment`.

It feels like a lot of this could/should be covered by linting rules. Am I the only one who runs into this?

Our team has the most inconsistent content for pull request body messages I have ever seen. Some will drop a link to a ticket without any other context, some will write a little paragraph that describes the intent of the changes, and still others put the ticket number in their pull request title and leave the body blank.

Personally, I enjoy the small narratives. The tickets are usually void of useful technical specifics (beyond maybe what component should be worked on).

So, my questions to HN:

1. How detailed should one make a pull request body?

2.Is there any value in pushing the point? We have lots to do and limited bandwidth, both points the CTO has tossed at me when I raise issues like this.

EDIT: format