Contributors mailing list archives
contributors@odoo-community.org
Browse archives
Re: Call for action - Metrics and KPIs for OCA accounting and finance dashboards
Re: Call for action - Metrics and KPIs for OCA accounting and finance dashboards
Re: Company as maintainer
by
Sicurpharma Srl, Francesco Foresti
Hi, I think there are several interesting points in this conversation, as well as Jean-Charles' project which could be very useful in my opinion - keeping track of specific modules' improvement and/or bug reports would make our work quite easier.
For example, knowing if a certain behavior has been fixed in a commit for the previous or next version of a module, and just migrating the commit instead of fixing it again.
In general, as I mentioned in a previous email, I think it would be extremely convenient for PMs and devs alike to have some space where all things related to a module could be collected - PRs, known issues, general discussions, if module is or will be discontinued in future versions and why...
--
But to keep discussion focus on maintainership:
Let's say Company A contracts Dev X to develop Module 1
Module 1 is built on specifications provided by Company A, to address use cases from customers of Company A, and ultimately it's PM from Company A who designs how the module should work functionally (of course based on technical expertise and guidance from Dev X)
If Dev X stops working with Company A, takes a sabbatical, leaves odoo development altogether or simply does not check notifications on email related to github account...
Are we sure that maintainership is better ensured by assigning the "maintainer" role to Dev X rather than Company A?
Ultimately I don't think it's a bad idea to have them both.
Francesco
Il giorno dom 30 ott 2022 alle ore 01:37 Jean-Charles Drubay <notifications@odoo-community.org> ha scritto:
Hi,I share the same observation more and more: there is a need to track/manage modules instead of repositories.Going in this direction I started to work on this topic which started around OpenUpgrade only at first until I realized that this need was broader than OpenUpgrade only:I have prepared a prototype to share the information per module and which can be tested here https://oca-cm-15.komit.linkThe Issues and PRs are linked to the module base d on the name of the Issues/PRs so at this stage it's not reliable.But naming conventions could be enforced by github checks I guess, at least for the PRs.Adding a notification mechanism should not be complicated.I am currently working on a v2 of the prototype.I am open to sharing the code, which I already did upon request.I am also open to discussions.
Best regards,
Jean-CharlesOn Sat, Oct 29, 2022 at 4:57 PM Pedro M. Baeza <notifications@odoo-community.or g> wrote:I'm afraid I don't have a solution for that. I'm subscribed to everything... and yes, lots of noise. But it also serves for having a whole picture, as "what are the modules I am interested in?" Maybe a new module arises over a feature I want.I use my self-called "5 seconds rule" for dealing with the huge amount of notifications: 5 seconds to decide if to discard it, answer immediately if it takes less than a minute, which can be my distraction window, or let it in my inbox for a later and more calm answer. This allows me to be reactive enough as well as not requiring too much time.Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
Francesco Foresti
Sicurpharma Srl
+39 333 8123 790
