New GRF-freenode process
Martinp23 on 2011-09-17As you might know, GRFs (Group Registration Forms) exist to form a relationship between a project and the PDPC (Peer Directed Projects Center). This relationship is relatively formal - personal details (address/tel no./etc) need to be shared by the project. For this reason, a severe backlog of GRFs has built up, since only a few staff have access to them (to protect this personal data). PDPC is the UK-based not-for-profit company which runs freenode. For most groups in our request backlog, their reason for registering is not to work with PDPC, but to gain a channel or cloak namespace on freenode. We've decided that running a separate, freenode-centric groups request system may help to move the system along. By requesting fewer details, we can open up this system to more staff, and hopefully keep on top of the queue of requests.
From now on, using a new, shorter form, projects can choose to file a GRF-f (for GRF-freenode) and submit a GRF for processing by freenode, rather than by PDPC. This sends details (no personal details, other than email address, will be required) to a system to which many more staff will have access. This new form will allow you to gain control of a channel and the right to issue cloaks much more quickly than previously, as we will double/treble the number of staff able to deal with requests. For now, please only apply if you are a 'priority' group - ie, you do not own the main channel of your namespace.
If you already have a group registered and approved with an old-style GRF, you do not need to do anything. Your registration remains valid. If you need to make changes to the registration, please contact staff on freenode who will, if appropriate, direct you to use the old (GRF) system. The GRF-f system cannot be used to update groups which filed under the GRF system.
If you have a request pending in the old GRF queue, you are welcome to re-file under the GRF-f system. This is likely to mean that your request will be dealt with much more quickly than otherwise. This approach supersedes the grfprocess@ system introduced a while back - unfortunately, we just weren't able to keep up with requests to that address.
You might be wondering where all of this fits into the GMS (Groups Management System) masterplan. When GMS is ready, we may need to ask all projects registered under the GRF-f system, and likely some projects which are already registered, to re-file. The GMS system will allow us to dispense with GRF-fs, and just build project<=>PDPC relationships, since forms will be able to be processed much more quickly. To be clear - it is quite possible that any registration made now may be revoked if a registration is not re-filed after GMS is released. If this does become reality, as much warning as possible will be given.
We hope that this will change will counter some of the ill-feeling around the GRFs system. In effect, the mentality is shifting from one of "GMS will clear the GRFs backlog" to "GMS will help us to serve groups better". We're no longer waiting for GMS to clear the queue. We're still looking for help with GMS: if you have Perl/Catalyst or web design experience and think you can help, join #freenode-gms.
Update 2012-06-09 - All group registration has been suspended whilst we evaluate the system and its implementation. A replacement should be available in due course, but for now it is not possible to register groups, and the link to the grf-f form has been removed.