Results of applying gherkinlint to the test definitions #180

DT, WG

Issue opened on 04/SEP, after initial checking done by Rafal Artych.
To be covered in the next MetaRelease track

Rafal indicates next steps regarding it is ongoing work in Commonalities and we can take advantage so far to make imporvements in tests definition. Pedro Díez García to check

16/OCT: Pedro is analyzing tests results, Conclusions will be reported in the issue. Maybe some feedback to be reported to Commonalities. Clear points will be addressed by means of new PR.

30/OCT: Only linter rule for filename.feature file is not working well (file may contain opearyionId and it is lowerCamelCase). For the rest, PR will be raised

13/NOV: PR https://github.com/camaraproject/CarrierBillingCheckOut/pull/191 generated to cover this issue

Linter configuration working well. Some points commented into Commonalities Track. Specific point considered into this WG due to the fact there is an endpoint named validatePayment.

There is a linter rule raising an error with logical operator “<=”. It seems to work fine with “>=”.
Pedro Díez García will show a workaround within the PR and Rafal Artych will check internally with Dev team anycase just in case a solution can be found.

27/NOV: After some discussion within PR#191 about the workaround, it is agreed to use it and consider some rewording to skip linter topic. This PR will be part of Spring 25 scope. WG will wait some time in order to have commonalities work consolidated. If finally Commonalities work would not be consolidated, we could merge within Carrier Billing WG in order to move forward and have initial linting
12/DIC: Waiting fror commonalities output https://github.com/camaraproject/Commonalities/pull/292

https://github.com/camaraproject/CarrierBillingCheckOut/issues/190

TEF Business (On Behalf of API Backlog WG)

Issue opened by TEF Business. API Backlog reference PR#94.

API Backlog would like to know as it is a functionality that affects an existing group, to have a validation checkpoint from the WG that this is a scope enhancement the WG want to accept, before approving it in the backlog and reviewing it in the TSC.

Key point for this issue is whether WG seems the functionality within WG scope to provide feedback.

TEF comments about intention is to have a separate functionality decoupled from Payment process.

Also indicates good to know the view in other Operators in order to have feedback from them

ORA indicates the funcionality may have sense in the scope of Carrier Billing. However it shows their worrying about this line eligibility function in terms of “privacy” (i.e. what is the message that this info “provides” to the 3rd party if the response is that te line is not eligible for the service, why it is not eligible so it may be understood as a line with any “weird” circunstance in the Operator). This topic has been also discussed in ORA in the past and it is seen as a functionality for “trusted partner”. So it would be helpful to be more precise in the proposal in order to evaluate it. Also comments initiatives like Credit Scoring or Device Data Volume also could manage this funcionality.

13/NOV: Pedro comments need to have more input from business to move forward on this topic
27/NOV: Pedro Díez García is checking with Business Product. Need to have more detailed information in order to be able to cover this within MetaRelease Spring 25. Check within next meeting whether this is covered or not. Talked offline to Ludovic as not able to attend the meeting. Rafal Artych also comments to their Business units to take a look to this and provide comments if any.
12/DIC: No additional information provided by Business. Other participants are welcome to comment within the issue. Conclusion is that not will be covered within MetaRelease Spring 25. Set to backlog.

https://github.com/camaraproject/CarrierBillingCheckOut/issues/194

WG Management

27/NOV: Parent Issue to compile all the MetaRelease Spring 25 associated work for Carrier Billing APIs. Some child issues already created (will be mentioned in Minutes as far as we are progressing on it). Some “child” issues to be created within this week (New features and Testing).

12/DIC: Set of child issues created:

• Issue Carrier Billing API Release Trackers for MetaRelease Spring 25  #195

• Issue Carrier Billing APIs - Aligment with Commonalities and ICM MetaRelease Spring 25 Guidelines #196

• Issue Carrier Billing APIs - API Readiness Checklist for MetaRelease Spring 25  #197

• Issue Carrier Billing New functional Features for MetaRelease Spring 25 #199

• Issue Carrier Billing Testing Enhancements for MetaRelease Spring 25 #200

  • Latest topic to be addressed once API Specs have maturity enough

Next action will be focus on generating PR for addressing Issue #196. Rafal Artych provided some input https://lf-camaraproject.atlassian.net/wiki/x/jIAQAw , in order to help API impacts identification. Expected for next week

AoB

WG

Other topics:

• M3 will probably be moved to middle half of January. Anycase let’s work with the initial target of 21st December for RC PR

• RM output about Releases: 2024-12-10 Release WG Minutes

  • Tanja already updated

    • carrier-billing v0.3.1

    • carrier-billing-refund v0.1.1

  • After meeting checked offilen with Herbert and Tanja an the message is clear “only the latest pre and public releases within a given meta-release. Transparency is given by the CHANGELOG.md and the releases in the GitHub repository  (additional, if there is a need, also the wiki is keeping a version history, but I won't use that).”. Next action will be remove these release trackers:

    • carrier-billing v0.3.0

    • carrier-billing-refund v0.1.0

    • Archived on 12/DIC - DONE