How does your team architect and push code?

We have issue templates for features, bugs, and incidents to help everyone write the best issue they can. Here's a feature template verbatim (just removed a few details, not changed):

  
  
  ### Summary
  
  
  
  
  ### Description
  ----------------
  
  
  
  
  ### Target
  ----------
  
  
  
  
  ### Instances
  -------------
  
  
  
  
  ### Proposal
  ------------
  
  
  
  
  ### Resources
  -------------
  
  
  
  
  
  
  /label ~feature
  /cc @jhadjar

Everyone writes issues and is expected to write issues whenever they encounter a bug or think of a feature or proposes an idea. We do a brain dump as soon as possible to written form, so that others who are not there may stay informed, and we don't lose the context and progress if we only do it a couple of months later. The issues and the comments capture the research, the findings, the objections, the resources, the conversation. We cross link to a Slack conversation sometimes, and often copy the relevant comment and answer those.

Now we have issues in our backlog. Based on our roadmap, what conversations we're having and how they fit into that roadmap, what we want (or do not want) the product to be in a few years, in a few months, in a month, in a week, we'll have conversations.

The most pressing issues will surface. Our product has a collaborative notebook feature, and we use it to have a collaborative notebook that contains the issues we want to talk about in the upcoming call for the product itself (I love that self reference). We go over them one by one, add remarks, sometimes add snippets of code, add action items, add rationale (why this is not important, why this must be done, why this will be postponed, why this needs to come after that, why do we not care about this), add impact on other parts to sort out, or whether we need to open an issue on a third-party tool/library's issue tracker.

Then after debating pretty much everything and objections have been cleared, the next steps and next issues are clear for everyone. Everyone knows what they should do: "OK, I'll take care of this, this, and then this. I'll need your help for that one, but I'll tell you when I get there".

Everyone takes the issues they want to do, because they mostly end up owning parts of the product that are stitched together to form a flow. There's a large overlap and everyone understands other parts, but people tend to truly be fast on parts they completely own and continue to refine them: bug, improvement, functionality, and the entire "flow" of the thing from end to end.

We exchange about the general implementation in the issue, but there's a huge autonomy and I sometimes will object to specific approaches or specific implementation ideas rather than validate. The team is good and right most of the time, so I only intervene on the 5% rather than spend time green-lighting 95% which would be a waste of time, energy, and create bottlenecks.

Sometimes the code in a merge-request/pull-request does not match the description, or introduced something (for example, it will leak an abstraction or introduce an external dependency on something we precisely want to stay stripped down), we'll talk about that and the implementation changes. In other words, sometimes you catch something downstream even though you have that conversation, issues, comments, talk.

We don't develop "to spec" for parts that don't require them (inter-machine? if there's a contraint, we'll just say S3 compatible, that's the spec). When I write an issue, I'll write and describe the problem, the job to be done, and the "Instances" of that problem happening (to whom, when, how many times, what impact and frequency). We ruthlessly prioritize. We're not Don Quixote. I may include an initial possible solution or implementation, but I will make it clear explicitly in writing that this is one implementation and that issue is a draft, and the code is a proof-of-concept, and will ask for others' thoughts. We focus on the problem, and we explore several solutions in the issue. Pros and cons, impact on other parts for each one.

We don't come up with the whole design and a formal specification before writing code. It's a waste of time at this stage. Just landmarks for navigation, and a few caveats for pitfalls (for example, beware zipbombs if you're doing something with zip files).

I read pull requests, see the changes (that allows you to catch things like the above), test them, interact with them, ask questions, make suggestions, then when it's all resolved, I merge them. Most of the time, they're already good to go.

I'm not writing code as often as I'd like to, but when I rarely do, it goes through the team's eyeballs in case I screwed something up.

Then someone from the team deploys to production, or I do. If there's a manual step in the process, there's someone whose area of the product is responsible for that who'll do it. Say we need to push a Docker image when we merge something, then my colleague (who resolved the issue and whose pull request I just merged) will push that image to a registry.