Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Business Need and Ability to pt language #47

Closed
wants to merge 2 commits into from

Conversation

praticandobdd
Copy link

🤔 What's changed?

According to Writing Great Specifications book it's a option describe user needs and abilities instead of features in a feature file

⚡️ What's your motivation?

For me e for my team that approach makes sense

🏷️ What kind of change is this?

Add new keywords to pt language

  • ⚡ New feature (non-breaking change which adds new behaviour)

♻️ Anything particular you want feedback on?

📋 Checklist:

  • I agree to respect and uphold the Cucumber Community Code of Conduct
  • I've changed the behaviour of the code
    • I have added/updated tests to cover my changes.
  • My change requires a change to the documentation.
    • I have updated the documentation accordingly.
  • Users should know about my change
    • I have added an entry to the "Unreleased" section of the CHANGELOG, linking to this pull request.

@mpkorstanje
Copy link
Contributor

Cheers!

Can you follow the instructions here https://github.com/cucumber/gherkin/blob/main/CONTRIBUTING.md#adding-or-updating-an-i18n-language

And please also update the changelog.

@praticandobdd
Copy link
Author

@mpkorstanje thanks for your orientation . I'll fix my merge request as soon as possible

@tulavalle
Copy link

This contribution is very important because it makes it possible to work closer to specification literature, such as the one cited by the author of the PR, that is, it makes it possible not only to describe resources, but also to document in order to make it clear that the documentation is not just about of functionality but rather of user needs and skills, leaving these intentions explicit in the documentation writing, allowing a documentation process based on BDD, much more robust and flexible for the needs of different contexts

@mpkorstanje
Copy link
Contributor

I'm closing this due to inactivity. If some one wants to add this in the future, please do feel free to create a new pull request.

@mpkorstanje mpkorstanje closed this Jun 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants