Re: Team Collaboration Considerations

[Benson Muite <benson_muite@emailplus.org>]

On 1/19/23 22:03, NightStrike wrote:
> 
> 
> On Thu, Jan 19, 2023, 13:33 Bernhard Reutner-Fischer
> <rep.dot.nop@gmail.com <mailto:rep.dot.nop@gmail.com>> wrote:
> 
>     On 19 January 2023 13:52:55 CET, NightStrike via Fortran
>     <fortran@gcc.gnu.org <mailto:fortran@gcc.gnu.org>> wrote:
> 
>     >You can, and people naturally do this, and I think it's great, but
>     >there's usually a response from someone saying "post that to the
>     >mailing list instead".
> 
>     The mailing list has a 20-30 year history with reasoning about what
>     currently is in the tree. I do think it is valuable to reason about
>     patches publically for others to see. And I'm aware that this might
>     not be regarded fancy nowadays by everyone.
> 
>     But that does not mean that using other means to collaborate should
>     not be used by some. Be it comp.lang.fortran, a webchat.oftc, or
>     other means, that's all fine of course.
> 
>     patches currently are handled differently, but I don't think that is
>     a problem isn't it.
>     Just post final patches to the list as long as that is regarded the
>     way to do final review and document approval.
> 
>     cheers,
> 
> 
> The problem is that patch tracking is unsustainable. You could go the
> other way and have a patch tracker automatically echo messages to the
> mailing list.
> 
Review is done voluntarily and by email.  The process has flexibility to
increase productivity but it may make it harder to get involved.  Email
threads and metadata make it possible to track patches. It is expected,
but not enforced, that posts to the mailing list follow convention.
Until a comment on a patch is posted, it is unclear if it will be
reviewed.  Build results are tracked separately and builds done when
needed.  An  open review process is good. Do all patches get timely
reviews?  Can this process be improved?

An analysis of a developer community:
https://carlschwan.eu/2021/04/29/health-of-the-kde-community/

Some tools:
https://chaoss.github.io/grimoirelab/
https://framagit.org/ervin/ComDaAn
https://github.com/gotec/git2net

Will try some of these to analyze GCC, though something new maybe needed
since the workflow is quite different.