MySQL geeks worldwide unite!
I am proud to announce that Georg Richter (our Community Engineering Lead) has updated the MySQL Community Development Program.
I am proud to announce that Georg Richter (our Community Engineering Lead) has updated the MySQL Community Development Program.
The updated program gives explicit suggestions for items you can work on, if you want to help out yourself and/or MySQL in development.
We have published a list of Development Worklogs (read: design outlines) and Bugs which we are very interested in getting help with. If you let us know your interest in coding one of the items, we can assign a MySQL developer to guide you in your work.
The intent of this assistance is to help you develop good code for MySQL. We hope this makes your end result function well, and makes it possible to merge your code easily with other MySQL code.
The list has been chosen by taking Worklogs for features we would like to include in the next development release, but for which we can't allocate resources currently. They are also of a suitable difficulty level so that we believe an external contributor can succeed in the implementation.
The chosen Bugs are of lower priority which we currently can't allocate a developer on, but which we think can be relevant for a fair amount of users. We also regard them to be of lower to intermediate complexity.
We welcome your feedback to the updated program!
3 comments:
I don't understand the rationale behind which bugs and WL tasks are included. For example, some of the bugs already have patches pending. #26622 is an example.
On a more general note, I don't think this change goes far enough to resolve the outstanding issues with the community contribution program. For example, it doesn't address the Community/Enterprise issues I mentioned in my blog. It also doesn't address the problem of contributing features that users want, as opposed to features that MySQL has on the roadmap.
Overall I would say it still does not make MySQL "feel" like an open-source project. Even though the source code is open, the development process is not what open-source developers may expect.
Thanks
Baron
Hi Baron!
Thank you for your feedback. You have several good question, and I will try to target them in the order presented.
1. The bugs are chosen with the following logic:
-We only look at verified and triaged bugs. ("Triaged" means that we have analyzed the bug and classified its Defect class, Impact, Effort to fix, Risk of fixing and its corresponding Priority.)
- For the Bug list we look at Bugs with Defect class D1-D4, Impact > 0 and Priority >0 (to ensure they have been triaged properly).
- The list is then further narrowed down by choosing only bugs that are fairly easy to fix (E1-2) and have little risk to fix (R1-2) in the affected version(s). - Final consideration is that the bug must be "verified" -- any other state means that someone internal to MySQL is already working on the bug.
Now, you correctly noticed a flaw in our list, since bug #26622 already has a patch pending. Thank you for highlighting this! The reason for this flaw is that the integration between bugs.mysql.com and the Bug list we publish is not yet automated, so we simply missed this. To fix the issue, we will put the automation in place. However, for the time being I recommend a user who wants to work on a bug to check if it is in verified state before contacting us. I hope we get this automation fixed rapidly, so there would be less confusion.
2. You ask about the rationale for the WL's included. Here I can only repeat my message, that we have chosen features which we are ready to help contributors work on, and which we are ready to include in the next development release.
In relation to 1.) I must though add, that a WL might be "up for grabs" by community user despite a implementor name being assigned already in the WL. The reason for this is because we use the "implementor" field internally to suggest who could/should do it. So, if you are interested in working on a WL, please contact us despite there being an suggested implementor added. (Note: falsely some of the listed WLs had "assigned" marked as status. This was false, they have now been corrected to "un-assigned", and they will be updated on Forge in the next sync run in a few hours).
3. In your comment you say: "It also doesn't address the problem of contributing features that users want, as opposed to features that MySQL has on the roadmap.". My comments to this are the following:
- As mentioned on the Community Development Program Forge page, we are very happy to hear community members to suggest new WL's (i.e. features) to be added to the Community WL list. Please send such requests, preferably with good details and reasoning to community-contributions _at_ mysql.com.
- We will review closely the WL/feature suggestions we get. However, before we add them to the Community WL list (whereby we agree to help with the work and commit to include it if ready into next development release we will review
a) how useful we regard the feature to be for our userbase
b) how complex the feature is, and if we believe it is doable & desirable (considering what other features are being added) for the next version
c) what assistance we can provide to help make the feature successful. I can envision even a tricky & complex feature to be approved if, for instance, the one suggesting the feature also is ready to implement it and the person has a good track record in MySQL development.
I can understand this approach might seem complicated to community members accustomed to more open and liberal projects. However, I believe the approach above is good, because it will ensure that those who spend time helping us
a) get appropriate assistance from us
b) has assurance that if their code is good, it will also be included in short timeframe into the codebase
c) don't spend their time in vain, which can happen easily if a contributor works in isolation and then learns late in the process that something is wrong with the patch and a lot of rewriting would be needed for the patch to be acceptable to include in the codebase.
I am glad to hear if you see ways to make the process simpler, while ensuring a good end result for the patch and for both parties.
4. You have some valid feedback in the blog posting you refer to. I will see if I can provide some feedback to this later on.
...
Post a Comment