IMP - Sunbird Issue tracker process

[Krishnaj20]

Dear @pramodkvarma @vijiurs @pkranga @rahul101001000,

Sunbird currently doesn't have a formal issue tracker mechanism for allowing contributors & community to log their issues. We’ve come up with this draft proposal detailing the approach to implement Issue Tracker on Sunbird. This draft was co-created by discussing with a few council members (@alok-os @madhucr @santoshilimi @vrayulu) and the six building block maintainers.

This document covers in detail about the issue types, the proposed workflows for these issue types, issue tracker tool recommendation, and what needs to be done by each building block to activate this process.

We are opening this document for feedback from the rest of the council members and community.
Please do note this process will have an impact on how the Sunbird contributions are currently managed. Hence, request you to go through the document and comment your feedback on the document.

The feedback window closes on 19th May. Looking forward to your feedback!

@vijiurs - Pls tag Khushboo to this thread. I'm not able to find her git handle - it is important that, as a member of the council, she goes through this proposal and shares her feedback.
@surendrasinghs - From Sunbird evangelization team, pls feel free to tag others as needed.

Cheers,
@chitranshu-keshav @vrayulu @luckynvdu @pallakartheekreddy

[surendrasinghs]

@jagadishbabu this might be of interest to you.

[rahul101001000]

Thanks @Krishnaj20 , the process is clear and well laid out.

Three thoughts -

1. Discovery -
   1a. How can we make it easier for someone to discover where to submit issues. Could you please point me to a reference implementation of the recommendation? Also, would they get email updates of the issue is updated?

1b. How can potential contributors discover first time tagged issues? Is there any concept of tagging and definition of tag types?

2. SLAs
   Any guidelines on how soon after issue is submitted will it be looked into or triaged?

3. Any good example of a vibrant community built around Jira? While Jira is great for tracking, I've not seen vibrant communities around it. Was that considered in the evaluation?

[Krishnaj20]

thanks @rahul101001000 for taking out time to review the proposal and share your feedback! Below is the response to your queries. Please do call out if you have any further questions.

Discovery: To address discovery related issues, we propose to include links of the issue tracker in both the building block microsite and in the github discussion forums. Spark uses their microsite to share the links to the issue tracker (hosted on JIRA) and forums (hosted on stack overflow).

With respect to notifications, users can choose to watch over issues for receiving automatic issue updates OR if the user is tagged to a response then also they will be notified.

Good for First time contributions: This is a good suggestion. In the proposal we have recommended the triage committee to include the complexity of the issue as well. The issues which are the least complex can be good for first time contributors.
We can propose each BB to tag the complexity of the issue with one of the below 3 labels:
a) Simple b) Medium c) Complex . The issues tagged as 'Simple' can be good for first time contributors.

SLAs: Each BB has the flexibility to define their triage turnaround SLAs. However, we will recommend a triage to happen once every 24 hours.

Open source projects using JIRA
There are quite a few open source projects which use JIRA for tracking their issues. Below are few references:
i. mongodb - https://jira.mongodb.org/browse/TOOLS-2726?filter=-5
ii. Majority of apache projects:
a. kafka - https://issues.apache.org/jira/projects/KAFKA/issues/KAFKA-13897?filter=allopenissues
b. cassandra - https://issues.apache.org/jira/projects/CASSANDRA/issues/CASSANDRA-17570?filter=allopenissues
c. log4j - https://issues.apache.org/jira/projects/LOG4J2/issues/LOG4J2-3494?filter=allopenissues
d. spark - https://issues.apache.org/jira/projects/SPARK/issues/SPARK-34827?filter=allopenissues
iii. Redhat uses JIRA extensively - https://issues.redhat.com/projects/WFLY/issues/WFLY-16384?filter=allopenissues
iv. mariadb - https://jira.mariadb.org/browse/TOOLS-16?filter=-5

Cheers,
@chitranshu-keshav @vrayulu @luckynvdu @pallakartheekreddy

[rahul101001000]

Very thorough thinking - thanks @Krishnaj20 !

[aishwaryashikshalokam]

Dear @Krishnaj20

Apologies for the late response, PFA my queries:

1. Where will the issue be created. Will it be on the discussion forum or on Jira?
2. The document mentions that a new enhancement will be captured in each BB template, I wanted to understand if an enhancement cuts across different BBs, how are we going to capture the requirement?
3. In case of prod bugs identified by the QA team, will the process remain the same for them, or will they also need to capture the issues as per the proposed process
4. What will be the frequency of triage?
5. Will any new enhancements identified will first be created as an issue and will be written as a story on Jira after it has been 'accepted'
6. From where will we get access to the different BB templates?
7. What will be the ETA to accept or reject any new feature request and minor enhancements

[vijiurs]

Hi @Krishnaj20 , The process is clearly defined. Couple of points

1. In case the defect needs fixes across different building blocks , how will the issues be captured - one common template or multiple templates ?
2. What’s the process to prioritize and plan the defects when the defect cuts across multiple BBs. Will there be a common triage for such cases ?
3. What would be the frequency of the Triage meetings.
4. Does the above process apply to Hot fixes too ?

[Krishnaj20]

@vijiurs & @aishwaryashikshalokam - thanks for sharing the feedback. My responses are inline:

a) Where will the issue be created. Will it be on the discussion forum or on Jira?
Discussion forum can be used to discuss about a issue or a new feature etc but the actual issue will be created using the issue tracker. The tool we are recommending for issue tracker is JIRA.
b) The document mentions that a new enhancement will be captured in each BB template, I wanted to understand if an enhancement cuts across different BBs, how are we going to capture the requirement?
I've answered this in the document. Irrespective of how many other building blocks your enhancement cuts across there will be one building block team which will anchor this new enhancement. For ex., interactive player contribution cuts across Knowlg & Ed building blocks but this enhancement is anchored by Knowlg.
c) In case of prod bugs identified by the QA team, will the process remain the same for them, or will they also need to capture the issues as per the proposed process
_Each BB's QA team will certify the changes as part of release testing process. And if an adopter who is using this BB encounters an issue, then the issue is reported by the adopter. _
d) What will be the frequency of triage?
This will be determined by the BB team depending on their existing capacity. Here is where we need more support from the community - the sooner we have more contributors elevating themselves as sponsors the more quickly we can turn around these triage meetings. Otherwise triage will soon turn into a choking point. To this end, some BBs have initiated community connect events. Request you to actively participate in these sessions.
e) Will any new enhancements identified will first be created as an issue and will be written as a story on Jira after it has been 'accepted'
New enhancements will start as a discussion in the discussion thread. Post that the tech design and PRD are reviewed by the community. (There will be a sponsor assigned to help you in this journey of creating the tech design & PRD). If the designs are approved then the actual implementation can start.
f) From where will we get access to the different BB templates?
What we have published now is a draft framework for issue tracker. Next steps would be for each BB team to define these templates. It will be highly appreciated if you can tag along with one of the BBs where you are actively involved to co-create these templates.
g) What will be the ETA to accept or reject any new feature request and minor enhancements
Acceptance & rejection will be based on the quality of tech & functional design artefacts. The creation of these artefacts is a journey undertaken by the contributor with the help of sponsor. Hence, I'm not sure ETA as a metric can be strictly defined here. However, the concern I raised in point d is applicable here as well. Currently there are very few users who can play the role of a sponsor. If this metric doesn't go up then each BB can handle only a certain number of new feature requests. The only way this metric can go up is by having more folks from community as sponsors.
h) In case the defect needs fixes across different building blocks , how will the issues be captured - one common template or multiple templates ?
Lets say an adopter encounters an issue in SunbirdEd BB. Adopter will follow the Ed BB template to report this issue. Ed team will do their due diligence and identify that this is a player related issue. Ed team will then raise an issue with Knowlg team as per Knowlg team's template.
i) What’s the process to prioritize and plan the defects when the defect cuts across multiple BBs. Will there be a common triage for such cases ?
Continuing the example from point h - Knowlg team will set the priority as per their guidelines. If it is a P1 then it goes the hotfix route. Other priority issues are added to the backlog. Common triages are not recommended. Just imagine, for all the open source components used by Sunbird (Cassandra, CK Editor, Fancy tree etc) we never attend their triages.
j) What would be the frequency of the Triage meetings.
Refer to my response to point d.
k) Does the above process apply to Hot fixes too ?
Yes, it applies to all types of issues.

[aks30]

Hi @Krishnaj20 , I went through the proposed workflow for issues and new features and it does cover all the aspects, so thank you for coming up with this draft.

I had a few queries and wanted to know your and everyone's thoughts on the same:-

1. Should there be a separate workflow for security vulnerability updates? Not sure putting it out in open would be right thing to do.
2. How do we provide support for somewhat old versions especially in case of critical bugs or security vulnerabilities or other issues, as not everyone might be able to always have the latest version and some issues might span across older releases as well.

[aks30]

@Krishnaj20 One more question was would common infra issues for e.g. with regards to some common tools or DevOps items etc be tracked as per the same process? I am not sure how current DevOps is getting partitioned as per BB architecture and hence the question. Do share any link which I can refer if that would help make things clear. Thank you.

[Krishnaj20]

@aks30 - my responses inline:

a) Should there be a separate workflow for security vulnerability updates? Not sure putting it out in open would be right thing to do.
This is a good suggestion. We did see most of the open source projects share an email ID to report security/vulnerability related issues. We can recommend the same for the Sunbird BB's as well.
b) How do we provide support for somewhat old versions especially in case of critical bugs or security vulnerabilities or other issues, as not everyone might be able to always have the latest version and some issues might span across older releases as well.
This question is more operational in nature and not related to the issue tracker framework that we are discussing in this thread. Request you to raise a separate thread in the respective building block where you have encountered this issue and engage with the TL & DC.
c) One more question was would common infra issues for e.g. with regards to some common tools or DevOps items etc be tracked as per the same process? I am not sure how current DevOps is getting partitioned as per BB architecture and hence the question. Do share any link which I can refer if that would help make things clear.
This question is not related to the topic we are discussing in this thread. I'd recommend you to initiate a discussion thread on Ed and engage with the Devops lead. They would definitely be able to help you out.

[pramodkvarma]

@Krishnaj20 can you please give me a summary? Finally catching up. We can get on a call. I am back in India now.

Btw, high level workflow assumes reflects a customer --> provider model (customer is reporting and provider is fixing or saying wont fix, with SLA etc). I personally do not like this mental model for an open source project where adopters are equal partners in the effort and there is no dedicated provider org etc. In that model, we can open up a challenge or encourage anyone including people who report to fix bugs, do a PR, etc. Workflow is very traditional. Let us see if we can imagine more open, collaborative, everyone can fix model.

[chitranshu-keshav]

@vinukumar-vs @pallakartheekreddy @anandp504 @sharathkashyap @reshmi-nair @vijiurs @kiranharidas187 @aishwaryashikshalokam @Prateek-slokam @aks30 @varsha-sl @pkranga @Prerna789 @rhwarrier @luckynvdu

Thanks everyone for taking out time to join the call.

Summarizing the discussion below and attaching the recording of the call for the benefit of all

• Revised version of the Issue tracker after incorporating everyone's feedback was presented and discussed with everyone.
• The updated lifecycle and workflow was agreed by everyone.
• The Pros and Cons of using GitHub and JIRA for implementing the issue tracker process was discussed. There was a consensus on the recommended option of using GitHub Discussion Forum for discussions and JIRA for issue tracker for the 6 major building blocks. The Specs Building Blocks will use GitHub for Discussion and Issue tracking both.
• We’ve also discussed additional scenarios, not captured in the draft document and concluded on what should be the ideal approach. Some of the items were outside the scope of this review and if required, they will be discussed separately.

If I've missed out on any other points discussed in the meeting, pls feel free to add them by responding to this thread.

People who could not join, please refer to the recording and post your questions in this thread.

Revised Document : Link
Recording Link : Link Passcode: *2b?FDQV

Next Steps:

1. All BB teams to action the set up of issue tracker
2. Changes to JIRA to facilitate the new workflows

CC:
@Krishnaj20
@vrayulu

[pramodkvarma]

Excellent @Krishnaj20, @chitranshu-keshav and everyone contributed towards this! Thanks for sharing the final doc (I went through it and it looks good) and recording.

[chitranshu-keshav]

@vinukumar-vs @pallakartheekreddy @anandp504 @sharathkashyap @reshmi-nair @rhwarrier @luckynvdu @SanthoshVasabhaktula @maheshkumargangula @vijiurs @kiranharidas187 @aishwaryashikshalokam @Prateek-slokam @aks30 @varsha-sl @pkranga @Prerna789 @tarang27 @aayushkedia95 @pritamps @karn-nahata @coolbung @ashokreddy1208 @gandham-santhosh @kameshbhr @mmanimegalai @pramodkvarma @rahul101001000 @alok-os @madhucr

Sharing the revised version of the document that includes additional details related to the issue tracker. This version of the document details, different types of contribution possible, how the issue tracker can be leveraged for some of these possible contributions and it has all the details at a single place for a contributor to contribute easily and effectively

The document is available at the sunbird community practice microsite as "Community Contribution Practice". The steps to provide feedback is at the end of the page. Please provide your feedback and suggestion to improve the document.

The document can be accessed here -> Link

cc @vrayulu @surendrasinghs