- Thomas Sundberg, Stockholm (java)
- Serguei Cambour, Tournai, Belgium (java)
- Mohan Krishna, Hyderabad, India
- Kushang Gajjar, Boston, US (cucumber.js)
- Simone Wood, Portland, Oregon, US (only QA, 6-month experience with Cucumber)
- Michele (Marton?), NYC, US
- Steve Tooke
- Julien Biezemans (host)
The focus of the MVP is to help newcomers/beginners getting started with Cucumber. The Getting Started section of SUMMARY.md is the main focus as well as the basics of the Cucumber user reference. Also, we agreed that the first contact with Cucumber should clearly state that it is not a testing tool, but a collaboration tool.
Even though the introductory section can then focus solely on automation, how to use Cucumber from a tech POV, etc., raising awareness early about the collaborative aspect of BDD/Cucumber should - we hope - help people not fall into the usual trap of writing tons of bad scenarios never communicated to the team.
Topics that were mentioned for the MVP:
- "get started with Cucumber", the "Get Started" section of
SUMMARY.mdshould be covered for the MVP. (Thomas) - "dos and don'ts with Cucumber", good and bad practices (Kushang)
- "examples and use cases" to help people learn (Simone)
- "matching groups in regexps" and more generally "step reuse" (Kushang)
- there should be a very simple introduction that clearly states the purpose of Cucumber. The rest of the docs should build upon it (Sergei)
- Explain the "why?" of Cucumber (Thomas)
We talked about improving the way we contribute to the project. There has been several large pull requests touching different topics and we agreed this should be avoided because they are difficult to review and give feedback on.
We insisted on making every pull request branch off the master branch, not another pull request branch.
The contribution guides were also mentioned again. Please read them carefully if yo have not yet:
https://github.com/cucumber/cucumber/blob/master/CONTRIBUTING.md https://github.com/cucumber/cucumber/blob/master/docs/contributing-to-documentation.md
We discussed how examples should be presented in the docs and identified different kinds. Simone nicely summarised the discussion on the Gitter channel:
@/all So, to follow up the discussion about examples from today's call: There are several forms of examples that I heard mentioned. There are inline examples that, for now, will be fairly succinct and accessible to beginners because those are the sections we're focussing on. There are longer and more detailed examples that might occupy a well tagged/commented page at the end of the document. Different sections of documentation could then maybe refer to these examples for those looking to look a little deeper into a topic. And then there are complete examples, which include the feature files, the steps, and the execution code for those steps. These might come from external libraries (like those that are linked to now at https://github.com/cucumber/cucumber/wiki/Projects-Using-Cucumber.) I also maybe heard the idea of there being fleshed out examples that are perhaps built specifically as examples or with comments aimed at helping people learn? I hope I didn't make all of this up -- I was still waking up so I was a little foggy. Do those general "types" of examples sound like a good starting point for organization and building out the summary page?
We're all happy with Gitter and GitHub.
Some people on the team struggled with the Gitbook Editor and how to work with Git/GitHub pull requests. We agreed to convene ad-hoc sessions on the gitter channel.
If you need help with anything, just shout /@all on the gitter channel and ask your question. If needed, remote pairing sessions can also be organised.
The gitbook editor seems to cause a lot of trouble. It creates commits for every file save and has other potential issues.
Thomas mentioned a bug with codetabs and gitbook. He reported the issue.
We agreed to run another confcall like this in about a month. A doodle needs to be sent to find the best timeslot.
Fridays are OpenSource day at Cucumber Ltd. We agreed Friday afternoons are a good time in the week to be available for people contributing to the documentation. While the gitter channel is open 24/7 (obviously :)), Friday afternoons are the best time of the week to get help from the team, organise remote pairing sessions, etc.
Cucumber Ltd:
- Send Doodle for another confcall in ~1 month (late August/early September)
- Create the confcall event on Google once the date is set
- Be available on Friday afternoons on the gitter channel.