[beam-site] 01/02: [BEAM-4802] Update the contribution guide (Dependency section)

[me...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

mergebot-role pushed a commit to branch mergebot
in repository https://gitbox.apache.org/repos/asf/beam-site.git

commit 9a4887b3d7595a367866fbf6cb2a0ca8aec8c876
Author: Yifan Zou <yi...@yifanzou-linuxworkstation.sea.corp.google.com>
AuthorDate: Wed Jul 18 20:18:37 2018 -0700

    [BEAM-4802] Update the contribution guide (Dependency section)
---
 src/contribute/dependencies.md | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/src/contribute/dependencies.md b/src/contribute/dependencies.md
index 11484cc..99ec6e6 100644
--- a/src/contribute/dependencies.md
+++ b/src/contribute/dependencies.md
@@ -44,7 +44,7 @@ One common solution for the diamond dependency problem is [semantic versioning](
 
 A big part of keeping dependencies up to date involves identifying outdated dependencies of Beam that the community should try to upgrade.
 
-Beam currently executes a weekly Jenkins job that tries to identify outdated dependencies for various SDKs. This Jenkins job generates a weekly report that is shared in Beam dev list. In the future we hope to automatically create JIRAs based on this report.
+Beam currently executes a weekly Jenkins job that tries to identify outdated dependencies for various SDKs. This Jenkins job generates a weekly report that is shared in Beam dev list.
 
 In addition to this, Beam community members might identify other critical dependency updates that have to be manually performed. For example,
 * A minor release of a dependency due to a critical security vulnerability. 
@@ -52,6 +52,17 @@ In addition to this, Beam community members might identify other critical depend
 
 These kind of urgently required upgrades might not get automatically picked up by the Jenkins job for few months. So Beam community has to act to identify such issues and perform upgrades early.
 
+## JIRA Automation
+
+In order to track the dependency upgrade process, JIRA tickets will be created per significant outdated dependency based on the report. A bot named *Beam Jira Bot* was created for managing JIRA issues. Beam community agrees on the following policies that creates and updates issues.
+* Issues will be named as "Beam Dependency Update Request: <dep_name> <dep_newest_version>".
+* Issues will be created under the component *"dependencies"*
+* Issues will be assigned to the primary owner of the dependencies, who are mentioned in the dependency ownership files. ([Java Dependency Owners](https://github.com/apache/beam/blob/master/ownership/JAVA_DEPENDENCY_OWNERS.yaml) and [Python Dependency Owners](https://github.com/apache/beam/blob/master/ownership/PYTHON_DEPENDENCY_OWNERS.yaml))
+* If more than one owners found for a dependency, the first owner will be picked as the primary owner, the others will be pinged in the issue's description.
+* If no owners found, leave the assignee empty. The component lead is responsible for triaging the issue.
+* Avoid creating duplicate issues. Updating the descriptions of the open issues created by the previous dependency check.
+* The dependency sometimes is not able to be upgraded, the issue should be closed as *"won't fix"*. And, the bot should avoid recreating issues with "won't fix".
+
 ## Upgrading identified outdated dependencies
 
 After outdated dependencies are identified, Beam community has to act to upgrade the dependencies regularly. Beam community has agreed on following policies regarding upgrading dependencies.
@@ -72,7 +83,7 @@ For manually identified critical dependency updates, Beam community members shou
 
 __Dependency declarations may identify owners that are responsible for upgrading respective dependencies.__
 
-Owners can be mentioned in a comment. Blocking JIRAs will be initially assigned to these owners (if available). Release manager may choose to re-assign these JIRAs. A dependency may have more than one declared owner and in this case the JIRA will be assigned to one of the owners mentioned.
+Owners can be mentioned in the yaml files. Blocking JIRAs will be initially assigned to these owners (if available). Release manager may choose to re-assign these JIRAs. A dependency may have more than one declared owner and in this case the JIRA will be assigned to one of the owners mentioned.
 
 __Dependencies of Java SDK components that may cause issues to other components if leaked should be vendored.__