Workflow 

Prerequisites 

GitLab Account Before you can contribute, you need a GitLab account that corresponds to your TYPO3.org username. You can manage your TYPO3.org account at my.typo3.org.

Access Requirements - For most projects: TYPO3.org account with GitLab access - For extensions.typo3.org (TER): Additional signed NDA required due to GDPR (user data protection)

If you don't have access to GitLab, the reason might be that your username is not present in the LDAP environment. To solve this, log in to https://typo3.org/ once.

User Roles & Permissions - Contributors: Can create feature branches, push commits, and create merge requests - Maintainers: Can merge into develop and main branches, review and approve merge requests

General Workflow 

1. Log in to GitLab
2. If you don't have access to the T3O project, ask one of the project maintainers

3. Look into the different repositories. Priorities are:

   1. Testing and reviewing open merge requests
   2. Solving existing issues
   3. Creating new issues
4. If you have found a merge request or issue, assign it to yourself
5. Work on your local development environment

Issue Workflow (Contributors) 

1. Find an Issue: Browse the repository issues and assign one to yourself

2. Create Feature Branch: Always branch from develop:

   git checkout develop
   git pull origin develop
   git checkout -b feature/issue-number-description
   

   Copied!

   Or use GitLab's interface to create a merge request from an issue.

3. Development: Work on your local environment (see Local Environment)

   • Make small, logical commits
   • Push commits regularly to your feature branch
   • Test your changes thoroughly
   • Ensure your branch stays up-to-date with develop

4. Create Merge Request:

   • Target: develop branch (never directly to main)
   • Mark as "Draft" while work is in progress
   • Remove "Draft:" when ready for maintainer review
   • Add clear description of changes and testing done

Coding Standards 

Follow TYPO3 Core coding standards:

• PHP: PSR-12 compliant, follow TYPO3 CGL (Coding Guidelines)
• JavaScript: Use modern ES6+ syntax
• CSS/SCSS: Follow BEM methodology where applicable
• Commits: Write clear, descriptive commit messages

Merge Request Workflow (Maintainers) 

1. Review Assignment: Maintainers review and assign merge requests to themselves
2. Code Review: Review the code changes carefully
3. Local Testing: Test the code locally on your development environment

4. Approval Process:

   • If everything is okay: Approve and merge into develop
   • If improvements are needed: Request changes and assign back to author
   • Ensure all tests pass and code quality standards are met
5. Merge to Develop: Maintainer merges approved feature into develop branch
6. Release Process: When ready for production, maintainer merges develop into main

Note for Contributors: You cannot merge your own requests. A maintainer must review and merge all contributions.

Deployment Process 

After successful merge to the main branch:

• Staging: Changes are automatically deployed to staging environment
• Production: Production deployment follows the project's release schedule
• Monitoring: Monitor for any issues after deployment

Branch Strategy & Permissions 

Protected Branches - ``main``: Production branch - Maintainers only - ``develop``: Development branch - Maintainers only - ``master``: For extensions - Maintainers only (legacy naming)

Contributor Branches - Feature branches: feature/issue-number-description - Contributors can create and push - Hotfix branches: hotfix/description - For critical fixes

Merge Flow .. rst-class:: bignums

1. Contributors create feature branches from develop
2. Contributors create merge requests targeting develop
3. Maintainers review and merge into develop
4. Maintainers merge develop into main for releases

Getting Help 

If you encounter problems:

• Check the FAQ for common issues
• Ask in the TYPO3 Slack #typo3-org channel
• Contact project maintainers directly