- Replace /XML/{doc,www}/ with /XML/ in SysId.
- Remove empty stylesheets in share/xsl and point share/xml/empty.xsl via
  XML catalog instead.
- Change the L10N layer in freebsd-*.xsl not to use localized XSLT
  stylesheets directly.
- Move share/xsl/* to share/xml and remove share/xsl.
- Remove obsolete share/web2c/pdftex.def.
		
	
			
		
			
				
	
	
		
			56 lines
		
	
	
	
		
			2.4 KiB
		
	
	
	
		
			XML
		
	
	
	
	
	
			
		
		
	
	
			56 lines
		
	
	
	
		
			2.4 KiB
		
	
	
	
		
			XML
		
	
	
	
	
	
| <?xml version="1.0" encoding="iso-8859-1"?>
 | |
| <!DOCTYPE html PUBLIC "-//FreeBSD//DTD XHTML 1.0 Transitional-Based Extension//EN"
 | |
| "http://www.FreeBSD.org/XML/share/xml/xhtml10-freebsd.dtd" [
 | |
| <!ENTITY title "Proposing Committers">
 | |
| ]>
 | |
| 
 | |
| <html xmlns="http://www.w3.org/1999/xhtml">
 | |
|   <head>
 | |
|     <title>&title;</title>
 | |
| 
 | |
|     <cvs:keyword xmlns:cvs="http://www.FreeBSD.org/XML/CVS">$FreeBSD$</cvs:keyword>
 | |
|   </head>
 | |
| 
 | |
|   <body class="navinclude.docs">
 | |
| 
 | |
| <p>The following paragraphs contain an advice from &a.kib;, member of
 | |
|   the Core Team, who summarizes what constitutes a good proposal, how
 | |
|   you as potential mentor, could increase your chances to have your
 | |
|   mentee granted a commit bit.</p>
 | |
| 
 | |
| <p>When proposing somebody, you should just forget for a moment that you
 | |
|   know the candidate personally.  After that, look unprejudiced on the
 | |
|   person's activity on the mailing lists, and evaluate the patches
 | |
|   submitted.</p>
 | |
| 
 | |
| <p>Now, you can ask yourself, is it enough confidence in both technical
 | |
|   abilities and the social behavior of the candidate, from what you see
 | |
|   only on the media?  If you do, then write down the reasons why are
 | |
|   you sure, using the said list of the contributions as the evidence,
 | |
|   and do include the reasoning in the commit bit application.</p>
 | |
| 
 | |
| <p>Due to several failures of the premature granting of commit bits, the
 | |
|   Core Team became quite sensitive to these criteria.  Most of the
 | |
|   members only see the activity of applicants on the lists, and not
 | |
|   seeing much there causes the cautious choice.</p>
 | |
| 
 | |
| <p>The Core Team wants to see a good list of the work already done for
 | |
|   &os; (e.g., the long list of the commits, submitted by the applicant,
 | |
|   the list of PRs opened etc.), which can make us confident that the
 | |
|   person has an established interest in the project, backed by the
 | |
|   technical ability and work done.</p>
 | |
| 
 | |
| <p>Also, the history of the good engagement with the community on the
 | |
|   public media, such as mailing list, is a deciding factor too.  The
 | |
|   Core Team wants to filter out the controversial personalities, since
 | |
|   it is almost impossible and highly undesirable to revoke the commit
 | |
|   bit, once granted.</p>
 | |
| 
 | |
| <p>Vendor-proposed maintainers for the hardware drivers usually approved
 | |
|   without applying the listed criteria.  Still, the Core Team requires
 | |
|   an experienced mentor for a vendor committer to avoid unwanted tension
 | |
|   and to make sure that vendor commits follow the Project procedures and
 | |
|   community expectations.</p>
 | |
| 
 | |
|   </body>
 | |
| </html>
 |