Mozdev.org

It's been a long time coming, but your requests to speed up the project creation process are coming to fruition.

Over the past couple years there have been two major pain points in setting up new projects: tracking the requests to make sure they're handled properly and actually creating projects (CVS trees and websites, mailing lists and newsgroups, and bugzilla products). We finally have the tools in place to handle tracking the project requests and creating projects which should dramatically increase the response time of setting up new projects.

We still have some work to do; we need to automate setting up Bugzilla products and we'd like to make it easier for existing project owners to get new projects setup, but we're well on our way to making those things happen.

We'd like to bring some changes to our project request form as well; we need to add items for our new features like Drupal and Mercurial, but we'd like to make it even easier for someone to submit a project request without having a lot of choices get in their way. If you have any suggestions feel free to ring in.

So feel free to stop by and request a project, we'll get you set up in no time.

Wednesday morning I had an email waiting for me about a new application GUID that an extension at Mozdev supported. This was interesting since we don't have new applications added to our list very frequently; upon looking up the GUID ({a23983c0-fd0e-11dc-95ff-0800200c9a66}) I was excited to discover that it was Fennec! I quickly filled out the information about the new app and went over to our supported applications list to see what extension now supported Fennec (it was Mel Reyes' MR Tech Toolkit at eMusic).
We're always excited to discover what new things projects at Mozdev are doing and we think it's great that developers are supporting applications like Fennec before they've even released a beta! Great work!

Earlier this year, there was confusion in the mozdev community surrounding mozdev's project adoption policy. This is the policy to be followed when a project hosted at mozdev has been abandoned and another project owner wishes to adopt that project.

As a result of the misunderstanding, we vowed to refine the policy and to make it more clear. We surveyed the existing mozdev project owners, asking for their opinions on adoption policy. Using the prevailing opinions as our guide, our discussions have concluded, and the following policy has been adopted.

We hope the policy is now more clear, and that you feel it protects access to your hard work. If you have any questions, please ask. This policy will be posted at http://mozdev.org shortly.

MOZDEV PROJECT ADOPTION POLICY

1. The user interested in adopting a project makes a formal request to feedback@mozdev.org. This initiates the adoption procedure. Emails sent by the user directly to the existing project owner or the project's mailing list are not a valid means of communicating adoption requests. IRC conversations, forum, wiki, blog entries, and other communications do not constitute legitimate adoption requests, even if those communications are with mozdev staff.
2. mozdev confirms receipt of the adoption request and determines whether or not the project is an adoption candidate. A project is not a candidate for adoption unless:

   a. The project is listed on the inactive projects list at http://www.mozdev.org/projects/inactive.html
   and
   b. mozdev, in its sole discretion, deems the project is a candidate for adoption.

3. If mozdev determines the project is a candidate for adoption, mozdev sends emails and/or other electronic communications to the project owner(s) asking for permission to grant administrative privileges to the project to the requesting user. The schedule for this contact is:

   First email: sent within a week of the original adoption request (providing step 2 has been met)
   Second email: if no reply has been received, sent one week after first email
   Third email: if no reply has been received, sent one week after secondemail

   If no email reply has been received two weeks after the third email, the requesting user is given adoption privileges by assignment of administrative rights to the project. If the project owner replies to mozdev within the stated period asking the user be granted adoption privileges, the user is granted such privileges. If the project owner replies to mozdev within the stated period asking the user not be granted adoption privileges, the user is not granted adoption privileges. If the project owner replies to mozdev after the stated period asking the user not be granted adoption privileges: the original project owner has the right to request that his project be returned to him. If it is not possible for the original and new project owners to agree to mutually satisfactory terms, control of the project reverts to the original owner. The new owner is welcome to fork the code, subject to accordance with the original license, and create a new project. Under no circumstances will mozdev arbitrate between project owners; project owners must communicate with each other directly.

   If there are multiple existing project owners, any one of the project owners can veto the adoption request.

4. When a project is adopted by a new owner, the previous owner(s) retain(s) their commit privileges so they can continue to work on their project if they choose.
5. The new project owner must read the mozdev copyright policy at http://www.mozdev.org/copyright.html. He should understand that certain project pages and materials may not be eligible for adoption because they are not open-source licensed. mozdev has no power to assign or reassign any copyrights.