[Tendrl-devel] [Release] Tendrl v1.0

[Sankarshan Mukhopadhyay]

On Tue, Nov 22, 2016 at 6:03 PM, Martin Kudlej <mkudlej at redhat.com> wrote:
> Hi Rohan,
>
> comments inline.
>
> On 11/17/2016 07:38 AM, Rohan Kanade wrote:
>>
>> We are pleased to announce the release of Tendrl v1.0.
>
> congratulations!
>
>
>> The first release brings capabilities for importing Ceph and Gluster
>> clusters and primary CRUD operations on cluster objects like Volumes,
>> Peers, Pools etc.
>
>
> I would like to ask where is complete list of features included in this
> release?
> Is there any other place(wiki page, solution on top of Github, something
> else) where Tendrl
> community do release planning?
> We(QE) would like to be part of this planning.

I have a different question and a fresh approach to this. The notion
of using Github issues to track PRs and Jira to track the stories was
based on ensuring a cross-team participation and collaboration.

If there is a lack of involvement in the release planning discussions,
this needs to be revisited. A cursory look at the meetings and
conversations seem to indicate that individuals with domain knowledge
in testing (I use this long form as a synonym for QE, which is really
a product specific function) have engaged in conversations.

What has happened however is that the complement to unit testing ie.
functional testing paths have not been added to the tasks/stories. In
a manner of speaking, we do not have acceptance tests which can help
us assess the state of each of the capabilities that are part of the
build which has been tagged. Developers have spent a few cycles doing
testing - but that is not expected to be a substitute for an
user/admin persona driven testing.

> It seems to me that Jira[1] is out of date.
> Also I've seen [3], [4], [5] and they aren't synchronized.
>

Allow me to turn this around - contributors to this project are
expected to collaborate. Developers will provide code and those with
skills in testing would be bringing their expertise to ensure we have
good releases to ship. If the baseline data sources which drive this
process are out-of-whack, why aren't they being updated? Do you not
have permissions/rights to do so? Or, is this a form of expectation
mis-match that is causing an impediment?

> Also I would like to ask if DoD [2] is still valid? Was there any changes?
> Should Tendrl 1 features follow all DoD?
> I'm open to discussion about this so we can enhance DoD to be better aligned
> to Tendrl team and project needs.
>

The 'Definition of Done' is a guideline. At this stage of the project
it encapsulates more of the aspiration ('where we should be') rather
than reality ('where we are'). A reason it is such because it
implicitly assumes there is a close-quarter collaboration in
development-testing-documentation. From outside-in, as I look at the
project, I do not see enough evidence of that. So, the DoD can only be
a gate when we have tests running across builds.

This isn't the first time I've stated this sentiment. But I certainly
find it challenging to use the DoD gate when we aren't running
functional tests on a build. We need to scope and assess the time and
effort investment required to make tests a reality. Unless we have
tests running on builds as automated jobs, it is harder to demonstrate
a level of confidence to potential consumers of the project artefacts.

This is as good a time as any to have a discussion around that topic
and put a plan in place.

> It seems to me that communication in community is not perfect and it should
> be enhanced. Especially communication about project planning. I think that
> we need to have Scrum master role in team if we would like to follow
> agile-like workflow. It seems to me now that our workflow is closer to
> Waterfall than Agile-like workflow.

I would disagree. I would like to think that between this list; the
establishment of office hours; the formulation of sprints and
execution of them - we have a good enough rhythm in place that relies
on communication. Distributed teams place unique challenges on
projects. However, distributed (not 'remote') teams are a reality - in
fact, every project has distributed teams (as a general rule of
thumb). Quality and consistency of communication can always be
improved - this is an iterative process. But it requires everyone to
chip in.

When we started the project and made the first few (hesitant?) steps
towards using the list, there was a lot of exhorting to do better and
default to open. If we aren't doing well on that - we have to improve.
I take your feedback in such spirit. And I seek your help in proposing
how we can do that.

> We work in team which is spread around the world so I think we should have
> in team somebody who will take care of team members. Majority of team is in
> India so I think it is logical to have Scrum master there.
> Please write what do you think about this. I'm open for discussion and I
> would like to enhance communication so we work on Tendrl as one team.
>
>
> [1] https://tendrl.atlassian.net/secure/RapidBoard.jspa?rapidView=4
> [2] https://github.com/Tendrl/documentation/issues/8
> [3] https://tendrl.atlassian.net/wiki/display/UD/Tendrl+Release+One
> [4]
> https://tendrl.atlassian.net/projects/TEN?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased
> [5] https://www.redhat.com/archives/tendrl-devel/2016-November/msg00053.html
> --
> Best Regards,
> Martin Kudlej.
> RHSC/USM Senior Quality Assurance Engineer
> Red Hat Czech s.r.o.
>
> Phone: +420 532 294 155
> E-mail:mkudlej at redhat.com
> IRC:   mkudlej at #brno, #gluster, #storage-qa, #rhs, #rh-ceph, #usm-meeting
> @ redhat
>                   #tendrl-devel @ freenode
>


-- 
sankarshan mukhopadhyay
<https://about.me/sankarshan.mukhopadhyay>