Architecture vs. project discussions…
During the last architecture committee meeting (https://etherpad.opendev.org/p/Kata_Containers_2021_Architecture_Committee_M...), we talked about disabling the Arm CI. This is an important discussion for the project, but it is not really "architecture" either.
So this made me think that we could either:
1. Make it more explicit that the AC meeting is our primary weekly meeting, and that we can also discuss non-architectural topics such as CI or upcoming talks. This matches existing practice, and it acknowledges that separation of concerns may be difficult (e.g. a change in repository like govmm is operational, but has architectural implications like "what APIs do we want to expose").
2. Take advantage of an existing weekly meeting that happens right before, the backlog review meeting. We are now "on a roll" and tend to finish this meeting early after having cleaned up the queue. We could decide to add an "agenda" for this meeting for discussion of more operational topics. We often have a few CI contributors there on a regular basis too, so it's not necessarily an extra load.
As usual, I believe that the correct solution will be a combination of both. As a first step, we could decide to use the existing EtherPad, and to simply add an "Operational issues" section that we could then discuss ahead of the AC meeting during the backlog review, so that we have solutions to offer rather than just problems to discuss.
What do you think? Christophe
Hi team,
Just a reminder that we will do our usual weekly backlog scrubbing and review one hour before the architecture meeting.
https://meet.google.com/ttm-kvqf-tog
If you have topics relevant to the Kata community but that you do not feel belong to the architecture committee, feel free to put them on the Etherpad (https://etherpad.opendev.org/p/Kata_Containers_2021_Architecture_Committee_M...) with a note, and we can probably find some time to discuss them before.
Thanks Christophe
On 2 Sep 2021, at 11:25, Christophe de Dinechin dinechin@redhat.com wrote:
During the last architecture committee meeting (https://etherpad.opendev.org/p/Kata_Containers_2021_Architecture_Committee_M...), we talked about disabling the Arm CI. This is an important discussion for the project, but it is not really "architecture" either.
So this made me think that we could either:
Make it more explicit that the AC meeting is our primary weekly meeting, and that we can also discuss non-architectural topics such as CI or upcoming talks. This matches existing practice, and it acknowledges that separation of concerns may be difficult (e.g. a change in repository like govmm is operational, but has architectural implications like "what APIs do we want to expose").
Take advantage of an existing weekly meeting that happens right before, the backlog review meeting. We are now "on a roll" and tend to finish this meeting early after having cleaned up the queue. We could decide to add an "agenda" for this meeting for discussion of more operational topics. We often have a few CI contributors there on a regular basis too, so it's not necessarily an extra load.
As usual, I believe that the correct solution will be a combination of both. As a first step, we could decide to use the existing EtherPad, and to simply add an "Operational issues" section that we could then discuss ahead of the AC meeting during the backlog review, so that we have solutions to offer rather than just problems to discuss.
What do you think? Christophe
Christophe,
On Tue, Sep 7, 2021 at 3:22 PM Christophe de Dinechin dinechin@redhat.com wrote:
Hi team,
Just a reminder that we will do our usual weekly backlog scrubbing and review one hour before the architecture meeting.
https://meet.google.com/ttm-kvqf-tog
If you have topics relevant to the Kata community but that you do not feel belong to the architecture committee, feel free to put them on the Etherpad (https://etherpad.opendev.org/p/Kata_Containers_2021_Architecture_Committee_M...) with a note, and we can probably find some time to discuss them before.
Please, before people start adding topics to a different meeting, which may result in discussions and decisions being made without a broader agreement, I'd suggest we discuss your proposal (preferably in this very same mail thread, but in the worst case in the *next*, as in September 14th, Architecture Committee meeting) and get to an agreement beforehand.
Of course, folks from the community are more than welcome to have any discussions they want in any means they want. However, we'd strongly prefer that discussions & decisions happen in places that we can easily track (such as GitHub issues or our mailing list).
[...]
Best Regards,
participants (2)
-
Christophe de Dinechin
-
Fabiano Fidêncio