I see. I guess if it’s accepted then you update the Status in the PR and merge it? There isn’t a single ADR format; there are several ADR formats that are successfully being used by different teams. The format I had in mind was the one introduced by Nygard (linked article). In our case, we generally first discuss the topic and then write the accepted decision in an ADR. So, there isn’t much room for discussion/voting afterwards.
But it’s good to learn about other people using it in different ways (a learning opportunity for me). It’s interesting that you mention ADRs stopping people from refactoring. Do you have any examples you could give?
we generally first discuss the topic and then write the accepted decision in an ADR. So, there isn’t much room for discussion/voting afterwards.
This makes sense. I guess it would cut down on the noise in the PR since, at the point of its creation, it’s already been accepted. Our repos have so many other teams contributing to them that it’s hard to rally everyone to build consensus on an ADR beforehand. I guess we could hold meetings, but having feedback in a PR allows us to go back and look at what discussions led to a decision later on.
How does your team build consensus before opening the PR? Is it through slack or some other chat tool? Or maybe a meeting?
We do that in a meeting. In some cases it may take several meetings before we can make a decision. But I think those are generally fruitful meetings (I don’t see them as waste of time). PRs give people a chance to think about these on their own pace, but when it comes to decision making, I feel like meetings actually save time (provided that people are sufficiently informed).
It’s also possible that our ADRs deal with higher level decisions and is therefore easier to establish some sort of a consensus. From your description (especially the “refactoring” bit) I thought maybe you are using ADRs at a level that is closer to code. I cannot really think of our ADRs stopping people from refactoring the code in any way :)
The meetings approach is interesting. I think we did those for RFCs but I remember they were very very long and unproductive. I think the company size matters when determining the right approach.
I see. I guess if it’s accepted then you update the Status in the PR and merge it? There isn’t a single ADR format; there are several ADR formats that are successfully being used by different teams. The format I had in mind was the one introduced by Nygard (linked article). In our case, we generally first discuss the topic and then write the accepted decision in an ADR. So, there isn’t much room for discussion/voting afterwards.
But it’s good to learn about other people using it in different ways (a learning opportunity for me). It’s interesting that you mention ADRs stopping people from refactoring. Do you have any examples you could give?
This makes sense. I guess it would cut down on the noise in the PR since, at the point of its creation, it’s already been accepted. Our repos have so many other teams contributing to them that it’s hard to rally everyone to build consensus on an ADR beforehand. I guess we could hold meetings, but having feedback in a PR allows us to go back and look at what discussions led to a decision later on.
How does your team build consensus before opening the PR? Is it through slack or some other chat tool? Or maybe a meeting?
We do that in a meeting. In some cases it may take several meetings before we can make a decision. But I think those are generally fruitful meetings (I don’t see them as waste of time). PRs give people a chance to think about these on their own pace, but when it comes to decision making, I feel like meetings actually save time (provided that people are sufficiently informed).
It’s also possible that our ADRs deal with higher level decisions and is therefore easier to establish some sort of a consensus. From your description (especially the “refactoring” bit) I thought maybe you are using ADRs at a level that is closer to code. I cannot really think of our ADRs stopping people from refactoring the code in any way :)
The meetings approach is interesting. I think we did those for RFCs but I remember they were very very long and unproductive. I think the company size matters when determining the right approach.