Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

1 files changed, 17 insertions, 4 deletions

diff --git a/CONTRIBUTE b/CONTRIBUTE
index b385d68c985..177a38cffd6 100644
--- a/CONTRIBUTE
+++ b/CONTRIBUTE
@@ -186,10 +186,12 @@ branch later.
 
 However, if you know that the change will be difficult to merge to the
 trunk (eg because the trunk code has changed a lot), you can apply the
-change to both trunk and branch yourself.  Indicate in the release
-branch commit log that there is no need to merge the commit to the
-trunk; start the commit message with "Backport:".  gitmerge.el will
-then exclude that commit from the merge to trunk.
+change to both trunk and branch yourself.  It could also happen that a
+change is cherry-picked from master to the release branch, and so
+doesn't need to be merged back.  In these cases, indicate in the
+release branch commit log that there is no need to merge the commit to
+the trunk; start the commit message with "Backport:".  gitmerge.el
+will then exclude that commit from the merge to trunk.
 
 
 ** Other process information
@@ -222,6 +224,17 @@ the tracker with the corresponding bugs/issues.
 GNU ELPA has a 'debbugs' package that allows accessing the tracker
 database from Emacs.
 
+Bugs needs regular attention.  A large backlog of bugs is
+disheartening to the developers, and a culture of ignoring bugs is
+harmful to users, who expect software that works.  Bugs have to be
+regularly looked at and acted upon.  Not all bugs are critical, but at
+the least, each bug needs to be regularly re-reviewed to make sure it
+is still reproducible.
+
+The process of going through old or new bugs and acting on them is
+called bug triage.  This process is described in the file
+admin/notes/triage.
+
 ** Document your changes.
 
 Any change that matters to end-users should have an entry in etc/NEWS.