| Re: [che-dev] Remove regular team updates within Community meeting |
Hello,
On 11/10/20 4:40 PM, Artem Zatsarynnyi wrote:
> Hello folks,
>
> Last Che Community meeting I've raised a topic to discuss the usefulness
> of the regular updates given by the teams involved in Che development.
> As there were different opinions and we weren't able to achieve a
> consensus on the subject, I decided to continue discussing it offline.
>
> A bit of background for those who weren't able to attend the latest
> meeting or not attending it on a regular basis:
>
> usually, at the end of every Che Community meeting, Red Hat team
> leads give an update
> on the teams' work done during the past week and what is planned for
> the current week.
> First, it's prepared in a written form in every Che Community
> meeting document, e.g. [1]
> and then every team lead is retelling it, one by one.
> As you see, in 99% these updates look like a list of the issues'
> titles given from GitHub with the links attached.
> Actualy it represents nothing more than just the sprints issues that
> are publicly available on GitHub for everyone.
>
>
> So, I expressed my doubts if we really need such a regular part of our
> Community meeting.
> Does it really make sense of preparing it and giving it during every call?
> During the call, I proposed to remove this part. Some people are sharing
> this opinion with me. Some people were against that.
> As I remember, there were suggestions to convert it to a different form,
> e.g.:
> - provide the written updates weekly to the community chat
> - make it convenient to see on GitHub (maybe labeling the sprint issues
> with the "current-sprint" label and posting a GitHub query somewhere?)
>
> In this follow-up thread, I want to ask the Community if someone would
> find it helpful to get such info about the current Che work?
> Or being able to get information related to the interesting area from
> GitHub, by tracking the issues/PRs, is completely enough?
I'm not sure how much of a community response you'll get, considering we
have ~3 consistently active community members.
I don't think we should be doing community team updates to begin with.
The whole concept of a "team" is a totally Red Hat centric one, where
Red Hatters are doing 95% (or more) of the work. Imagine we had 50% of
the work done by community contributors (a goal we should aspire to
achieve), and 50% done by Red Hatters. Would it make sense to have
individual community contributors post updates every week? No.
Furthermore a "team update" is only so useful when those writing the
updates are doing the work. As soon as some percentage of the work is
done by those in the community the report becomes inaccurate because it
doesn't show the whole picture. I don't write about non-RH committers'
PRs in my team updates and I don't plan on doing so either.
We have more than enough publicly available metadata to track work in
the various Che repos, to the point where it's not unreasonable to ask
community members to find the information themselves. Some examples include:
* Area labels
* Release milestones
* Subscribing to repos they are interested in seeing activity in
* Following users whose contributions they are interested in
We can make this process easier by outlining in the Che README:
* GitHub queries to see the issues for each relevant subject area
* Links to the relevant repo for each subject area
There are also the public mattermost channels where anyone is free to
ask any question.
There also seem to be some internal RH people (who are not responsible
for writing these reports, by the way) looking for team updates. In
addition to the public information described above, interested internal
onlookers can also:
* Attend the standup call of any team
* Attend the sprint planning/prioritization call of any team
* Lurk in any team's internal/external chat channels
* Reach out to team leads for status updates on specific items of interest
As far as copying the SoS report goes, well that's not quite as simple.
The SoS report is an internal reporting tool for Red Hat management, and
contains information about CRW as well as Red Hat confidential details.
It's not a question of dumping a copy of the SoS report somewhere,
because often such a report would need reviewing and tweaking.
I suggest we make the improvements to the Che README as outlined above,
and stop doing the team updates all together. The community call will
then be topic based, with no agenda topics resulting in a short call, or
no call at all.
Eric
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev