I am excited to announce that we will be allowing our External Developer Community to make Merge Requests to base! This may not be a surprise to you if you were joined Wednesday's "Chat with Developers" (or watched it on YouTube).
Our plan is to allow a Beta Period to get a solid handful of MRs to evaluate and determine if this is something we can continue to offer from the community.
How does it work?
Process for an External MR to base.
- Determine the changes you would like to make to base
- Create a fork of base if one is not already available to you
- Ensure the fork is up-to-date
- Add your changes to the fork
- Create a Merge Request with a target of 'main'
- Create a Developer Support ticket, specify the following:
- The Reason for the Merge Request (problem you are trying to solve, etc.)
- A hyperlink to the MR in question
- If necessary, an example of the issue in action
- Any relevant attachments
Frequently Asked Questions
What criteria are expected for Merge Requests to be accepted?
The above criteria is the requirement for the Developer Support Team to move your request onward for evaluation. This does not assure acceptance. While Configura will make a 'best-effort' attempt to communicate reasoning for not immediately accepting a merge request, time and availability of resources may prevent us from providing detailed feedback explaining why a merge request was rejected. In addition, we will not be able to accept binary file types into base for security reasons.
What sort of code changes are expected?
Smaller, less significant Merge Requests will have a chance of being successful over large, sweeping changes. Here are some general ideas of where merge requests will land:
High Likelyhood - Comment changes to better explain functionality within the code base
Medium Likelyhood - Single Interface changes adding optional parameters, renaming variables/methods/functions and small functionality/code changes (adding a single-line missing `case` to a switch statement), pure code fix, bug fix, changes to access modifiers or "visibility" (private to public)
Low Likelyhood - Large or Massive changes to functionality (removing snap alternatives from snapping checks), High "risk" items to other customizations
What might I need to consider that I don't normally?
There is a possibility that your bug fix, while it makes complete sense for your extension will negatively impact other extensions already extending that functionality. Please keep this in mind for any issues you submit, and consider how your changes may impact others.
How long can I expect to wait for my code changes, to get merged? Released?
It is hard to predict how long it will take before merges are done. While we can prioritize the changes made for External Merge Requests slightly, it will be up to the Configura to allow or not allow the change in at a timing of their convenience. Configura is responsible for migration changes necessary to allow the fix, as well as explaining the ramifications to our QA team. Configura understands priorities they have to work on, as this is also a factor in the time they can dedicate to these tasks.
Once the merge is accepted, at the earliest, the next major release would contain the changes. As migration efforts for the next release begin, the next reasonable release time would be two major versions in the future.
How long will the beta period last?
The plan is to allow the beta to continue until August 1st. Once the beta period has ended, we will no longer allow forks from base. During this period, we will evaluate internally the effectiveness of these merge requests. If we find positive value in what was accomplished from the merge requests, we will make the process permanent.
How will you evaluate effectiveness?
There are a few criteria we will consider for evaluating effectiveness:
- Time spent on merge requests that were not accepted
- Time spent deviating from important project work
- Effectiveness of code changes
- Value of accepted changes to the user community
When will we know what decision Configura has made?
We will evaluate and make a decision by Q4 of this year.
Will there be any changes to the process in the 'beta' period?
While we will try and keep the process the same we may run into 'hiccups' from time-to-time with the process. In order to get your changes in, it's possible you may be asked to perform a pull, rebase, or try your merge again. While we are striving to make this process as pain-free as possible, complications are certainly possible. We will make sure these needs are communicated appropriately.