Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device.
Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
This issue has been an issue for a while. It is marked as needs review, but is now closed. Need to check if its now working. We need to define what we mean by qualifier. Will be discussed in lab tomorrow. In regards to process, is this what is expected? JK - is there a process for developers to notify us when they close a ticket. JE - Do not think the developers pay attention. RT - we can work that into our process, when there is a SIG label we should now to look at it again. What if there is a bug with no SIG label. Would the SIG like to be notified. CT - Not clear how this knowledge is surfaced. If we have a bug, or a ticket, that gets closed with no work being done, how do we make sure that that is not the end of the conversation? RT - Having it reviewed in lab is a great idea. That way it can be brought back to the developers if needed. CT - reading the comments in the ticket it seems as if the requirements we have and what the developers think we need are not the same. There is not the same understanding of what we are trying to do. Where is the documentation of how things are supposed to work. Is clarification needed? Do we need better JIRA’s that better define our functionality. WC - is there a way for the SIG to be tagged? Is there an in-between stage, so that they can leave their comments and we can discuss before they close the ticket? JE- We are working with a lot of issues that were created before our process was in place, and things weren’t as well defined. Ryan, can you bring this back to the developers so that the SIG can discuss before they close the ticket. RT - this should be on case to case basis so we don’t create a bottleneck of open tickets. Can be done when clarification is needed. If something is closed and the group still thinks there is an issue, tickets can be reopened. JE - sometimes can be reopened, sometimes we need to create a new ticket with defined expectations. KR - maybe we can have the person who reported the issue tagged? CT - in this particular case, the reporter is no longer working. Next step for this is for the lab to start workshopping use cases and better define what “qualifier” means. Should we keep this on the agenda for next week? Can someone from lab report back next week? JE - great idea, especially if we need to do housekeeping and create a new ticket. CT - would like a report from lab. There needs to be output from lab so that we are not starting from scratch in the meeting. How is the knowledge from lab transferred back to the group? JE - we can create a document in our SIG drive. I can create a document and share the folder so anytime this comes up we can refer to it. Like we did for MARC modifications. CT - we can test that out. JK - Are the devs testing on snapshot? RT - that’s dependent on the issue. the team does test on specific releases. If the issue is on an old release it may be a problem. CT - its very hard to test anything complex is snapshot. JE - will be tested in lab. A document will be created.
JE -Does this meet our expectations? WC - I forgot to take the tag off when notified that it was closed. Not clear to me if this was solved for just this issue or for the logs in general. JE -I too had no idea what the message meant. WC - now I know what the message means, but not helpful for new users. CT -reminds me of the inconsistent behavior in the system. JE - we need more help for the logs. There is a list of log messages. We should add these type of messages to it and start a list of what would be helpful in log messaging. Is it ok to remove the tag from this ticket? WC - yes. JE - the main story regarding DI log enhancements is open and tagged. RT - the issues are linked. If the current messaging is ok but could be better its good for us to know so that we can improve going forward. I’ll update the ticket to it reflects the long term plan to add several features. JE - worth looking for reporting tickets as well to see what they cover. RT - will look into both issues and let the group know if we need a separate one for reporting. WC - wasn’t clear to me what the epic was about. Should we let you know what would be helpful for us for the message to say. RT - It’s always helpful to have the user input. CT - We see similar messages for completely different issues. Very generic messages. If replacing with natural language will this continue? In the cases where the message is not specific enough, what are options for providing guidance? RT - We want the messages to be as helpful as possible but there are technical limitation. I’d like to look into making the messages as granular as possible. We need to document when the same message comes up in more than one scenario. For others, we need to make the messages as clear as possible. LF -for messages that are very specific, is there a table that lists all the possible error messages? we could start to parse them? JE - there isn’t an official list but there is one that I will share. Can we continue this discussion in the next meeting?
New Requested Topic: Ability to view application log
Added on 2024-08. When DI was in the planning phase with, there was a request to be able to view the application log. Examples were provided from other systems. This is still needed. This was shown as "server logs" in the original wireframes. From Lab Session last year.
In the 2025-08-06 discussion, it was noted that if you cancel a job, that this job didn’t appear in the list of jobs using that profile in the “Jobs using this profile” section when previewing that job in Settings.
Brief Log View in DI Landing Page
Preview in Settings/Data Import of that Job Profile
JE - will create the Jira for this issue so we have more time next week for the issues we discussed today.
CT - thanks to Jennifer for spearheading the work of the SIG and making sure our process is in place and working.
Actions/Decisions Needed
To do
Roadmap Discussion (At same time of a new release)
MVP Discussion (at the same time of a new release)
