There's plenty of jargon that goes around which may overwhelm a newcomer. See edX's glossary for any terms that may not be listed here.
A custom LMS front-end, used by one of our clients (Yonkers). It replaces the standard Open edX LMS front-end.
Calendly is a handy web service that allows you to share a link so that people can easily choose a time for a meeting based on your availability. See Calendly's homepage.
This refers to changes in forks that aren't present in upstream. Code drift must be maintained (ported, tested, sometimes rewritten) across new release versions, and so adds to our maintenance costs. OpenCraft aims to minimize code drift by upstreaming as much as possible and consolidating the rest into common branches that are shared among several client sites.
Software that stores current infrastructure information and configuration. It allows us to configure various services across dynamic and distributed infrastructure. See Consul's homepage.
In-house Jira bot used to simplify some actions like filling spillover reason to a Google Spreadsheet directly from Jira. See Crafty' repository.
The process of "discovering" the set of tasks from client requirements. This is usually the first step when an epic is created. A completed discovery involves scoping the tasks, making time estimations, and assessing the level of effort needed for the work.
A software stack composed of Elasticsearch, Logstash and Kibana. This stack is moslty used to store logs, metrics and to create dashboard. We are actually using the ELK stack for logs.opencraft.com. See ELK's homepage.
A big chunk of work that has one common objective. It could be a feature, customer request or business requirement. These would be difficult to estimate or to complete in a single iteration. Epics contain smaller tasks meant for iterative completion over one or more sprints.
A firefighter is a sprint's facilitator. The firefighter's responsibilities include handling emergencies, attempting to unblock people, watching over potential spillovers, and more.
Gandi is a French company providing domain name registration, web hosting and related services. We are using it as our DNS provider. See Gandi's homepage.
Short for "General Data Protection Regulation". This is a regulation in European Union law on data protection and privacy in the EU. See GDPR's Wikipedia page.
Short for "Independently Deployable Application". These are separate applications which may integrate with Open edX via APIs or by sharing authentication.
Web service used to store software metrics and errors. See New Relic's homepage.
Short for "OpenCraft Instance Manager". It's our in-house, open source deployment service for Open edX instances, which:
- Manages configuration and automates deployments for client production sites.
- Provides continuous integration by watching our PRs against the
edx/edx-platformrepository and automatically spinning up a sandbox for the PR's version of the platform. See how to spin up sandboxes.
Atlassian tool used to alert and page team members in case of incident. See Opsgenie's homepage.
Short for "Open Source Pull Request". This is the edX process for reviewing pull requests from the open source community.
Also known as "story points", these represent the approximate "level of effort" and time a task would require. See Task Workflows for a description of how we use points. The cells collectively vote on story points for the tasks in the upcoming sprint, see Process for sprints for details.
Represents an environment that should be isolated from the production one. It allows us to test things without potentially breaking the production. This term could refer to Ocim instances created to test pull requests.
Also know as "user story", is a specific Jira ticket that represents a user need or a specific scenario. This is the most common Jira ticket type we are using.
Task refinement / Agile poker#
Atlassian's tool to track time which is integrated with Jira. We use it to log time against Jira tickets and track epic budgets. . See Tempo's homepage.
Maximum amount of time allocated to a task -- going over the timebox is not permitted. If it looks like there is a risk of going over the timebox, ping Braden and/or the epic owner to discuss.
We sometimes also use timeboxes to manage our sprint commitments. For instance, if a task needs to be started during a given sprint, but the assignee does not have time to complete it, we may timebox the task to a maximum amount of hours for the current sprint, and complete the remaining work during the next sprint. Because this affects sprint commitments, this type of task timeboxing must be decided before the sprint begins, and agreed to by the epic owner.