| | 1 | = RFC 9: GDAL Paid Maintainer Guidelines = |
| | 2 | |
| | 3 | Author: Frank Warmerdam[[BR]] |
| | 4 | Contact: warmerdam@pobox.com[[BR]] |
| | 5 | Status: Approved |
| | 6 | |
| | 7 | == Purpose == |
| | 8 | |
| | 9 | To formalize guidelines for the work of maintainers paid out of GDAL project |
| | 10 | sponsorship funds. |
| | 11 | |
| | 12 | == Responsibilities == |
| | 13 | |
| | 14 | 1. Analyse and where possible fix bugs reported against GDAL. |
| | 15 | 2. Run, review and extend the test suite (via buildbot, etc). |
| | 16 | 3. Maintain and extend documentation. |
| | 17 | 4. Assist integrating new contributed features. |
| | 18 | 5. Help maintain project infrastructure (mailing lists, buildbot, source control, etc) |
| | 19 | 6. Provide user support on the project mailing lists, and in other venues. |
| | 20 | 7. Develop new capabilities. |
| | 21 | |
| | 22 | Bug fixing and maintenance should be focused on GDAL/OGR, but as needed will extend into sub-projects such as libtiff, libgeotiff, Shapelib and MITAB as long it is to serve a need of the GDAL/OGR project. |
| | 23 | |
| | 24 | In order to provide reasonable response times the maintainer is expected spend |
| | 25 | some time each week addressing new bugs and user support. If the maintainer |
| | 26 | will be unavailable for an extended period of time (vacation, etc) then |
| | 27 | the supervisor should be notified. |
| | 28 | |
| | 29 | == Direction == |
| | 30 | |
| | 31 | The maintainer is generally subject to the project PSC. However, for day |
| | 32 | to day decisions one PSC member will be designated as the supervisor for |
| | 33 | the maintainer. This supervisor will prioritize work via email, bug |
| | 34 | assignments, and IRC discussions. |
| | 35 | |
| | 36 | The supervisor will try to keep the following in mind when prioritizing tasks. |
| | 37 | |
| | 38 | * Bug reports, and support needs of Sponsors should be given higher priority than other tasks. |
| | 39 | * Areas of focus identified by the PSC (ie. multi-threading, SWIG scripting) should be given higher priority than other tasks. |
| | 40 | * Bugs or needs that affect many users should have higher priority. |
| | 41 | * The maintainer should be used to take care of work that no one else is willing and able to do (ie. fill the holes, rather than displacing volunteers) |
| | 42 | * Try to avoid tieing up the maintainer on one big task for many weeks unless directed by the PSC. |
| | 43 | * The maintainer should not be directed to do work for which someone else is getting paid. |
| | 44 | |
| | 45 | Substantial new development projects will only be taken on by the maintainer |
| | 46 | with the direction of a PSC motion (or possibly an RFC designating the |
| | 47 | maintainer to work on a change). |
| | 48 | |
| | 49 | Note that the maintainer and the maintainer supervisor are subject to the |
| | 50 | normal RFC process for any substantial change to GDAL. |
| | 51 | |
| | 52 | == Reporting == |
| | 53 | |
| | 54 | The maintainer will produce a brief bi-weekly report to the gdal-dev list |
| | 55 | indicating tasks worked on, and a more detailed timesheet for the supervisor. |
| | 56 | |
| | 57 | This is intended to provide visibility into status, accomplishments, and |
| | 58 | time allocation. It also gives an opportunity for the PSC to request a |
| | 59 | "course correction" fairly promptly. |
