Re: Team Collaboration Considerations

[Jerry D <jvdelisle2@gmail.com>]

On 1/19/23 10:21 PM, Benson Muite via Fortran wrote:
> 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.

What I am envisioning as a workflow is to retain posting to the gfortran 
list for approvals to commit. At this stage patches are refined and 
tested already by the developer and therefore have the most value for 
the public and people wanting to learn.

Mattermost would be used for internal discussions and collaboration. 
People can post questions and examples back and forth quickly by phone, 
or web browser or desktop app interfaces. This can be done in real-time 
much better than email. Email certainly is a necessary component as a 
formal review process.

Regarding patches and such. Mattermost supports "boards" which are 
actually modeled after Kanban, a very well established methodolgy. See 
https://en.wikipedia.org/wiki/Kanban.

It allows one to see at a glance where things are at.  Individuals can 
chat with each other privately and we can also set up specific channels.

For example, I have set up for the gfortran workspace the following 
channels:

	Finalization
	Gfortran Development
	Gfortran Front End
	Gfortran Help
	Gtk-Fortran Development
	Gtk-Fortran Help
	Native Gfortran Coarrays
	Town Square - for anythin

There is nothing sacred about these, they are simply things I thought of 
during initial setup. Thes can evolve as developers determine and learn 
this tool. The point is, the channels are focus points.

I have a board where I am tracking bugs we know have patches submitted 
in bugzilla that need to get tested and committed.  So, this tool does 
not replace bugzilla either. It is a tool for us to visualize where we 
are, Work In Process.

We can create a board to track patches if we choose. In a sense, I am 
doing that already.

By the way, anyone who wishes to get on the team, send me an email. We 
will keep evolving this tool as we go.

Cheers,

Jerry