The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in our bug tracker.
There are three pages tracking JS files for documentation:
Unclaimed JS docs files: Nobody is working on documenting these files yet. You can claim a file by commenting on the post.
In progress JS docs file tickets: These files have patches with documentation or someone is working on creating a documentation patchpatchA special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing..
2. Set up a local copy of the developer version of the WordPress codebase using Varying Vagrant Vagrants (VVV). WordPress is versioning using SVNSVNSubversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase., but you can also use GitGitGit is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/. (the VVV link for how to do that).
3. Read Opening a Ticket to learn how to create a TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.ticketticketCreated for both bug reports and feature development on the bug tracker..
Always update your local copy of WordPress trunktrunkA directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. before editing the file and creating patches. Use svn up or git pull, as appropriate.
Generate the patch from the root directory of your WordPress SVN or Git checkout.
It is best to name your patch file with the Trac ticket number you created, such as 12345.patch or 12345.diff. Either file extension is acceptable.
Suggested Title formats could be “JSDoc correction for path/to/file.js” or “Improve documentation for path/to/file.js”.
The Type should be defect (bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.).
Assign the ticket to the Component the file is associated with.
Leave the Version blank.
Upload your patch to the Trac ticket you created, and add the keyword has-patch.
Make sure to leave a comment describing your newly-uploaded patch. Simply uploading patches doesn’t trigger a notification for anyone watching the ticket.
Note: Documentation changes should not mix with code changes (even whitespacing) unless the ticket specifically calls for both.