MAINTAINERS: Update instructions

Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I0e06ac5f92109757143897f3d331aeea0cefe4b9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68705
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>

MAINTAINERS

@@ -14,27 +14,17 @@ Please try to follow the guidelines below.  This will make things
 easier on the maintainers.  Not all of these guidelines matter for every
 trivial patch so apply some common sense.
 
-1.	Always _test_ your changes, however small, on at least 1 or
-	2 people, preferably many more.
 
-2.	Try to release a few ALPHA test versions to gerrit. Announce
-	them onto the coreboot mailing list and IRC channel and await
-	results. This is especially important on coreboot core changes,
-	but also for device drivers, because often that's the only way
-	you will find things like the fact revision 3 chipset needs
-	a magic fix you didn't know about, or some clown changed the
-	chips on a board and not its name.  (Don't laugh!)
+1.	Make sure your changes compile correctly in multiple configurations. In
+	particular check that changes work for various boards in the tree that
+	it affects:
 
-3.	Make sure your changes compile correctly in multiple
-	configurations. In particular check that changes work for all
-	boards in the tree (use abuild!)
+	Test with: `util/abuild/abuild -c $(nproc) -t vendor/boardname`
 
-4.	When you are happy with a change make it generally available for
+2.	When you are happy with a change make it generally available for
 	testing in gerrit and await feedback.
 
-5.	Make your patch available through coreboot's gerrit code review
-	system, and add the relevant maintainer from this list as a code
-	reviewer. Be prepared to get your changes sent back with seemingly
+3.	Be prepared to get your changes sent back with seemingly
 	silly requests about formatting and variable names.  These aren't
 	as silly as they seem. One job the maintainers do is to keep
 	things looking the same.  Sometimes this means that the clever
@@ -45,36 +35,27 @@ trivial patch so apply some common sense.
 	(util/lint/checkpatch.pl) to catch trival style violations.
 	See https://www.coreboot.org/Coding_Style for guidance here.
 
-	PLEASE add the maintainers that are generated by
-	util/scripts/get_maintainer.pl as reviewers.  The results returned
-	by the script will be best if you have git installed and are
-	making your changes in a branch derived from coreboot.org's latest
-	git tree.
-
-	PLEASE try to include any credit lines you want added with the
-	patch. It avoids people being missed off by mistake and makes
-	it easier to know who wants adding and who doesn't.
-
 	PLEASE document known bugs. If it doesn't work for everything
 	or does something very odd once a month document it.
 
-	PLEASE remember that submissions must be made under the terms
+	ALWAYS remember that submissions are made under the terms
 	of the OSDL certificate of contribution and should include a
 	Signed-off-by: line.  The current version of this "Developer's
 	Certificate of Origin" (DCO) is listed at
 	https://www.coreboot.org/Development_Guidelines#Sign-off_Procedure.
 
-6.	Make sure you have the right to send any changes you make. If you
+4.	Make sure you have the right to send any changes you make. If you
 	do changes at work you may find your employer owns the patch
 	not you.
 
-7.	Happy hacking.
+5.	Happy hacking.
 
 Descriptions of section entries:
 
 	M: Maintainer: FullName <address@domain>
 	   Must be registered to Gerrit (https://review.coreboot.org/).
-	   Should have experience with upstream coreboot development.
+	   Should have experience with upstream coreboot development and
+	   +2 rights.
 	R: Designated reviewer: FullName <address@domain>
 	   These reviewers should be CCed on patches.
 	L: Mailing list that is relevant to this area