{scrollbar} |
----
Contributions can enter this process from many different avenues. The most likely and the easiest to identify would be those contributors that send an email or post a thread in a forum stating they have code/documentation/translation/testing to contribute.
Some contributions may start as a discussion between the Community Leader or a Pentaho Developer and a potential contributor. For example, Pentaho asks community members to document the resources they have available to work with, and we use that information to match members up with projects that suit them. At the start, there is no contribution, just an offer to complete a task.
The Community Leader should be notified at the beginning of this process, as that person is responsible for tracking contributors and contributions in total.
If you are unsure whether to start the process as the result of interaction with the community, contact the Community Leader .
All contributions and potential contributions MUST start with a JIRA case! Try to get the contributor to create it. If it's their first contribution, or if it's faster/easier, create the case for them, but point out that our process requires that they create a case in our case tracking system.
With every contribution, a new team is formed. Just like when you are assigned a new feature as part of our development process, there is always a discussion that takes place between you and another dev teammate about design, implementation and the fantasy football standings. This same discussion should in some part occur with your community teammate.
A community member will be "assigned" to the case. This just alerts a Pentaho team member that there is community involved in the case, and who they are. This will also be used to later automatically identify contributors for attribution. The community member should be able to make edits and notes to the case, but not change status or assignment.
A Pentaho team member will be assigned to the case. This is no different than how we manage all other prioritized JIRA cases. The big difference is that this will be a case in your bucket that most likely will not be prioritized for an upcoming release, although that is not always the case.
It is then up to the developer to communicate with the involved community member and facilitate progress on the case. This should not be a time-consuming, hand-holding exercise. It should be more about mentoring, defining requirements, getting the community person over humps and gaps that would be obstacles to anyone who doesn't sit next to a developer in our office regularly.
Regular action items during this step include but are not limited to:
At this point , we hope to receive the code, documentation, bug report, whatever the contribution may be. We need to accept the donated resource through JIRA. This is critical in order for us to automate tracking and publishing attribution for contributors, as well as understanding the amount of tangible contributions we are receiving. When the contribution is a bug fix posted in the forum, or the contributor is ignorant to our process and emails it to a developer, we need to enter the contribution into JIRA ourselves, and assist the community by again pointing them to our process for future contributions.
Since this process is iterative, a single JIRA case can potentially have multiple attachments representing contributions. The attachments should have enough information submitted with them that the history of the submissions is evident, and justifies the contributions as being part of the same case.
More times than not, the contribution process will be started, but the community member doesn't come through. We never receive the contribution. This should be handled just like cases that are reprioritized in the normal course of the development cycle. Hopefully, the community member and developer have captured in the JIRA case all the valuable info regarding the work that has been done up until the point of abandonment (more on that in a moment). The developer, declaring the task abandoned, will mark the case as inactive. The case will remain assigned to the developer and the community member, until it is on the internal project roadmap as a priority, or the community picks it up again. This commonly will occur with a new community member needing to scratch the half-scratched itch.
So how do you know when to declare a community contribution effort abandoned? There are several clear and some fuzzy signs that the effort is going on hold indefinitely.
The contributed resource has to ultimately be linked to the original JIRA case. Whether this is the same record in JIRA or two that we link, the goal is to be able to identify a number of things:
Once the assigned Pentaho team member has received the contribution, it must be reviewed for quality, accuracy, and license or copyright issues. In the case of code contributions, they must be merged and tested. In any case, with every contribution you should ask and be able to answer positively the following questions:
If the contribution passes muster, then you can check it in to SVN WITH THE JIRA CASE NUMBER REFERENCED IN THE COMMIT COMMENT.
Update the JIRA case appropriately, FLAGGING THE CASE AS AN ACCEPTED CONTRIBUTION. This facilitates the automated attribution.
Giving the contributor attribution in the release notes and on our web site can be automated from this process. In the short term, Community will be responsible for gaining permission and giving attribution to contributors.
The Pentaho team member needs to provide feedback to the community person. The following are some things that need to be included: