Drupal, a powerful open-source content management system, relies heavily on the active participation of its global community. Contributions span a wide range of activities, including code development, bug fixing, feature enhancements, documentation, marketing, event organization, and financial backing. Each contribution plays a crucial role in shaping and advancing the Drupal platform.

Introduction To Drupal Contribution

Giving back to a project that supports the way you work and probably live every day could be a strong enough cause for you to actively contribute to and develop an open source project. Of course, giving back to a project that supports the way you work and probably live every day is a reason. But if you’re searching for a little more motivation to donate, these are some of the perks that we’ve seen others receive after doing so:

  • Because of your contributions, Drupal is able to maintain its usefulness and keep pace with the changes that take place in all of its dependencies over time.
  • You have the ability to increase your Drupal knowledge, which will, in turn, allow you to develop superior applications for your customers.
  • It gives businesses who sponsor time for contribution an advantage over their competitors because their developers are obtaining more experience and expertise by displaying themselves as an expert in their field.
  • Collaborate and get together with other people who are interested in the same things as you are.

Reasons To Contribute To Drupal

To get started, you will need to make an account for yourself on drupal.org and then fill up that account with the necessary information.

Drupal

Source: Specbee

Finding and Selecting an Issue to Work On

After the user account has been created, the next step is to identify the problem that needs to be fixed. It is entirely dependent on the individual field that you are interested in:

  • You can locate a problem by looking through the issue queue, which can be found at https://www.drupal.org/project/issues. You can conduct a more targeted search by selecting ‘Advanced search‘ and making use of the available filters.
    • Tags for issues: Problems can have a variety of labels attached to them. The “novice” tag indicates that the issue needs a basic remedy, and any beginner would be able to choose it as their solution. The “Needs documentation” tag indicates that this issue requires some documentation revision, and so on.
    • Status of the issue Once an issue has been established, it will progress through a number of phases. You could pick the next measures that need to be taken for the issue to move ahead based on the current condition of the issue. 
    • The priority of the issue is determined by it. The issue could be a critical bug, or it could be a simple remedy. The priority of the issue is defined by it.
    • Issue type: This field describes the nature of the issue, such as whether it is a bug, whether it is a job, or whether it is a request for a new component that will be integrated into the project.
    • Specified project: This section gives you the opportunity to directly identify the project in which you are most interested.

Issue-filter

  • You might also begin by working on a project that has always intrigued you by going to the module/theme/profile page at https://www.drupal.org/project/project_name>. Alternatively, you could begin working on a project that is completely new to you. Look for a link labeled “All issues” in the sidebar on the right of the screen (https://www.drupal.org/project/issues/project_name>?categories=All).
  • You might also fix a defect that you found while working on a project that was present in the core or in any contributed modules, themes, or profiles. Additionally, doing so is the responsible way to give. Even when working on projects, individuals should make it a habit to maintain their “contributor mode” turned on; doing so provides the possibility to discover and provide a solution to previously unknown problems.

Understanding the Life Cycle of a Drupal Issue

After an issue has been raised, it will progress through a number of states. The following is a list of the many issue states that you might come across:

  1. When a new issue is created, it will automatically be placed in the Active state.
  2. Needs review – The issue’s state should be changed to “Needs Review” once it has been chosen, the patches have been successfully submitted, and all of the test cases have passed.
  3. When there is still work to be done on the problem, the issue is said to be in the “Needs Work” state.
  4. Once the problem has been examined by any contributor, it is transferred to the “Reviewed & tested by the community” (RTBC) state, where it is reviewed by a member of the core community team. This state is referred to as “Reviewed & tested by the community.”
  5. When an issue is resolved, it is moved from the RTBC state to the Fixed state and given the status of “Fixed.”
  6. After the issue has been brought to the level of Fixed, it will transfer to the Closed (fixed) stage automatically within fourteen days. The problem has now reached its conclusion in this state.
  7. When an issue is created that is a duplicate of any prior one, it is immediately closed as Closed (duplicate), regardless of whether or not the problem was created by the same person.
  8. This status indicates that the problem cannot be fixed in any way. It is also known as “closed.”
  9. This state indicates that an issue reported is providing the functionality that it was supposed to, and as a result, it has been moved to the “works as designed” stage. Closed means that the issue is providing the functionality as intended. To put it another way, the problem that was brought up is not a defect but rather a feature.
  10. Closed (cannot replicate) is the state that an issue is moved to when it is determined that it cannot be reproduced.
  11. Closed (outdated): The state of an issue can be changed to Closed (outdated) when it is either unfixable because it is too old or when it is fixed inside the context of an issue for another module.
  12. When a Patch needs to be transferred to work with different versions of the Drupal/Contributed module, it is referred to as being “to be ported.”
  13. When an issue, feature, or bug has been postponed by the author or the community, it does not require a solution at this time.
  14. When a problem is reported, but the maintainer of the Contributed module states that additional information regarding the issue is required before it can be addressed, the issue is said to be postponed (the maintainer requires more info).

Create A New Problem

To generate a problem for the module. Create a new problem by going to the module’s issue queue at https://www.drupal.org/project/issues/project_name>?categories=All and clicking on the Create a new issue button.

Create a new issue

Source: Specbee

The second thing that has to be done is to provide specifics regarding the problem that needs to be solved.

Source: Specbee

  1. Title: Include the issue’s title in the heading.
  2. Project: The name of the project will be chosen for you automatically.
  3. Category: The next step is to choose the project’s category. There are 5 different categories.

 

  1. Errors in the system’s functionality are referred to as bugs. For instance, a mistake in PHP, the loss of data or memory, incorrect or misleading documentation, incorrect or misleading user interface wording, etc.
  2. Task: These “needs to be done” before the release despite the fact that they are not functional bugs. Refactoring code, for instance, to make it more easily understandable and maintained is one example. Increasing the number of automated tests, bringing the code up to date with the latest APIs, enhancing the coding standards, etc.
  3. This is a request for fully new functionality to be added to the module, and it is referred to as a feature request.
  4. Support Request In the event that we require assistance with any aspect of the module or have questions regarding the functionality of the Drupal core. Support requests can be tagged, and the question can be added.
  5. Strategy: You should use this tag whenever you have a problem that cannot be handled by addressing a single issue. There will frequently be many sub-steps linked to “child” difficulties that pertain to plan issues.

 

  1. Priority: Choose the level of importance you attach to this issue. The following are the possible outcomes: Critical, Major, Normal, and Minor. If the situation isn’t extremely critical, opt for the regular approach. You also have the option of selecting it as normal and allowing the reviewer or maintainer to make changes to it if necessary.

 

  1. In Status, make sure that Active is selected for new issues.
  2. Select the version of the project in which the problem has to be rectified, and click the “Version” button.
  3. Select the component that is most closely related to the problem. These can be altered at a later time. The module serves as the foundation for these components here. The available choices change depending on the module being used. 
  4. Assigned: The problem may be given to any person you choose. It is not necessary, and the responsibility can be handed out at a later time. 
  5. Labels: Label the problem using the proper labels. If we do not have any prior knowledge of the issue tags, we can leave this blank. This is not required, although it can be marked at a later time.
  6. An overview of the problem and its connections: Increase the size of the field, and we will have the editor fill in the issue’s specifics. There are some default heads in the editor, and if we don’t want them to appear in the issue details, we can replace them with something else.
  1. Concerning the parent issue: to assign a tag to the parent problem.
  2. Concerning the relevant issue: to label the associated concern.
  3. Files: We have the option of either adding the files that are relevant to the issues or uploading the patch to the issue while we are creating it under the files heading. And rescue the situation.

subsequently to having saved the issue. The newly generated problem will be added to the problem queue of the relevant module as soon as possible.

The link https://www.drupal.org/node/add/project-issue/drupal should be followed in order to create a new issue for the Drupal core. In addition, the procedures will be the same as when creating the problem in the module. However, there are some recommendations for the creation of a core problem, and those are going to be posted on the URL that was just provided.

Source: Specbee

While developing the central issue, you should keep these criteria in mind at all times.

Creating And Submitting Patch

Here, we have two different cases.

  1. Make a new repair patch.
  2. Bring the existing patch up to date.

In order to generate a fresh patch

  •  Navigate to the tab labeled “version control” on the module. The page can be accessed at the following link: https://www.drupal.org/project/project_name>/git-instructions.
  • Choose the department you want to work on, then click the Show button.

Source: Specbee

You may retrieve the git command by clicking the display button; then, you need to copy the command, paste it into your terminal, and run it, after which you can change the directory to the cloned module.

  • To resolve the issue, make the necessary adjustments.
  • The following is the command that will create the patch: 

git diff > <issue-description (optional)>-<issue-number>-<comment-number>.patch

Source: Specbee

  1. The title of the issue will serve as the issue description; however, all of the letters in the title should be written in lowercase, and any spaces should be filled with underscores. This is not required at all.
  2. The URL of the issue will include the number of the current issue. This will be a one-of-a-kind identifier for the problems, and using it will be required when naming the patch file.
  3. The newest comment id will be uploaded into this particular comment, which is shown by the comment number.

Comments

Source: Specbee

Consider the possibility that you need to incorporate a new file into the patch. The newly added file will not be tracked, and the git diff command will not be able to track it either.

In order to incorporate a new file into the patch

  • Use the git add command to include the newly created file.
  • Run

git diff HEAD > <issue-description (optional)>-<issue-number>-<comment-number>.patch

To bring an existing patch up to date

  1. Make a copy of the project that requires the patch to be added to it.
  2. Navigate to the page containing the issue, right-click the patch link, and then click the Copy address link button.
  3. Use either the curl or wget command to download the patch to your local computer.

Using the curl command, you may download the patch by doing the following:

curl -O <paste the address link of the patch>

  1. To apply the fix, execute the following command:

git apply <patch name>

  1. Once you have applied the patch, the changes that were made by the patch will be reflected in your local. Create a new patch and add any additional modifications that are necessary to the existing one.

It is necessary for us to generate an interdiff file whenever we update an existing patch. The only thing that is contained in an interdiff file is the difference between the previous patch and the most recent patch. The reviewer will have a better understanding of the changes made in the new patch as a result of this.

This is the command to use in order to build an interdiff:

interdiff <old-patch> <new patch> > interdiff_<old-patch-comment-number>-<new-patch-comment-number>.txt

Imagine that you have two patches, one that is an outdated download called 3302030-2.patch and another that is an updated version that you’ve made called 3302030-3.patch. The following command would be used to create an interdiff comparison between these two files:

interdiff 3302030-2.patch 3302030-3.patch > interdiff_2-3.txt

Submit a Patch

After putting together a patch, it is necessary for us to send it in.

Proceed to the issue page in order to submit the fix.

  1. Make available the metadata

Issue metadata

Source: Specbee

Modify the status of the issue so that it reads “needs review” in the metadata. If the issue is already assigned to you, you should withdraw the assignment and add or remove tags according to the situation.

  1. Provide credit for this contribution

Attribute

Source: Specbee

If you are working for any organization, you should select the appropriate settings and add the name of the organization. Taking this into consideration, the credits will be granted to the organization in addition to you once the problem has been resolved.

  1. Under the remark box, add an explanation of the changes that have been implemented in the patch.
  2. Select the file to be patched as well as the file to be interdiff and upload it under files.

files

Source: Specbee

Here, we have added the files one at a time, and after selecting each one, we have selected the upload button. The file will be uploaded when you click the upload button, and it will be added to the list below.

Please take note that running interdiff is optional when introducing a new patch.

  1. Once the file has been successfully uploaded, select the “Save” button. This will cause the problem page to be updated, and we will be able to view the patch that was uploaded along with the new comment number.

It is recommended that patches for core problems be provided using the same approach.

Review a Patch

You are now familiar with how to search for a problem, construct a patch, and upload it. What should I do now? How can we guarantee that the correct fix will be committed as quickly as possible?  In order to make progress on the issue, it is vital to review any patches that have been submitted. If you don’t feel comfortable creating lines of code, a good alternative would be to review the fixes that have already been submitted.

Before we get started, I would like to strongly suggest installing the Dreditor extension on your browser.

Dreditor

Source: Specbee

You will have access to a ‘Review’ button for the patch/interdiff files with this feature. The modifications are shown in an easy-to-read style upon clicking the button.

Review

Source: Specbee

 

patch

Source: Specbee

 

Changes

Source: Specbee

Now that everything is in place, let’s look for a topic to discuss!

  • You should filter out the problems that have the status “Needs Review.”
  • Choose one from the options on the list.
  • Read through all of the comments, and select the most recent patch that was published to the issue.
  • Check that the patch has turned green, indicating that it has successfully passed the test cases.

patch-test

Source: Specbee

  • Download the file containing the patch, and then apply the patch locally into your core/module/theme/profile by running the following command: 

git apply <patch-file-downloaded> -v

  • Check to see if it is functioning as expected or if it need additional work.
  • Alter the issue’s status and add comments, preferably with accompanying photographs and videos to back up your claims. Your reply ought to include specifics such as whether the patch was applied to the most recent version, the procedures that were taken to replicate the problem, the behavior of the problem both before and after applying the patch, and so on.
  • If everything seems to be in order, you should set the status to ‘RTBC’.
  • If there is any potential for additional work or adjustments, the status should be changed to “Needs Work.”

Additional Ways to Contribute Beyond Code

You can contribute to the Drupal project in many different ways, including improving its quality and reaching more people. One of these ways is through writing code for the project. You have the ability to tailor the manner in which you contribute to our community to reflect the interests that you have. The following are some of the areas of contribution:

  • By Acting as a Mentor – If you already have some experience with contributing, you may be able to assist others in getting started by acting as a mentor, either online or in person.
  • To Documentation – Every single piece of documentation that is part of the Drupal Project was created via the generous contributions of individuals from all around the world, just like you.
  • Sharing Your Knowledge One of the most essential things you can do to help the Drupal project is to share your knowledge of Drupal with others. You can do this by publishing blog entries, delivering a presentation at a local Drupal Group event, a DrupalCamp, or a DrupalCon, becoming a trainer, and many other things.
  • Volunteering at in-person or online Drupal events such as meetups, sprints, and other similar gatherings can count as event planning experience.
  • By Marketing – You have the opportunity to collaborate with other marketing teams located all over the world to develop marketing and sales materials branded with the Drupal name. These materials can be shared and utilized by anybody who is providing Drupal services.
  • Contributing Modules and Themes – Working together on Drupal projects such as modules, distributions, and themes is an essential component of being able to make a meaningful contribution to the Drupal community.

Staying Engaged: Community and Updates

  • Slack
  • The Drupal community is organized around a primary Slack workspace that is simply referred to as ‘Drupal.’ You can access Drupal at slack.com. 
  • You will discover a variety of channels devoted to a wide range of subjects, including #support, #bugsmash, #donate, #drupal10rediness, and many others.
  • Blogs
  • Blog entries regarding Drupal are written by participants in the Drupal community. 
  • Even YOU have the potential to become one of them!
  • Social Media – Twitter, LinkedIn, etc
  • If you follow any Drupal-related accounts, you may stay up to speed on all of the ongoing developments and activities that are occurring in relation to Drupal.

Understanding Drupal’s Code of Conduct

Because Drupal is open source and our community is expanding, it is absolutely necessary for us to maintain the characteristics that brought us here. The following is a list of some of the points that pertain to conduct.

  • Cooperate with one another.

Collaboration is essential because Drupal is used by such a broad community. We will be able to pull the best out of the Drupal platform if we work together as a team.

  • Show proper deference.

The Drupal community and its members treat one another with respect because of the significant contributions that each person contributes to Drupal.

  • When we are unsure, we should seek assistance.

Nobody is flawless in Drupal, and no one in the Drupal community is expected to know all there is to know about everything. In order to find solutions to a wide variety of issues, questioning is strongly encouraged.

If you are a victim of harassment, a witness to harassment, or if you need assistance with the administration of Slack, please contact your peers or the Slack administrator.

The link to the document at https://www.drupal.org/dcoc will take you to a more in-depth explanation of the code of conduct.

Conclusion

Now, in the end, we hope that through this post you were able to gain knowledge on how to jumpstart your Drupal contibution journey? Hpwever, if you are planning to hire dedicated Drupal developers who can help you gain the best of of your project.

Appic Softwares is a leading Drupal Development company which you can choose for further Drupal development process. So, what are you waiting for?

Connect with us now!

This blog is inspired by <https://www.specbee.com/blogs/guide-to-start-your-drupal-contribution>