This is intended as the 'Coles Notes' version of a four-part post. The rest of the proposal can be found at the following links:
- Part 1: Today's Project Application Process
- Part 2: Where the Existing Process Breaks
- Part 3: The Proposal
- Part 4: Sanity Check - Wait a Minute Here ...
Or, if you prefer, download a copy of the entire proposal in Word format.**
The 'Coles Notes' summary
The proposal outlined in the posts linked above could be positioned as a ‘badges’ approach, ‘ladder’ approach, ‘gates’ approach, or ‘staged progression’ … but for each, the concept is the same – a few different classes of contrib projects, with defined tasks/checks/requirements for progression from one class to the next.
Essentially, the proposal can be summarized as follows:
-
Add ability to publish ‘-dev’ releases in sandbox projects.
-
No review required to publish a sandbox ‘–dev’ release
-
To claim a project namespace, projects must meet the following requirements:
- Meet Drupal Licensing requirements
- Run through ‘Coder’ cleanly (ignoring false positives)
- Abide by basic namespacing and documentation related coding standards
- Have a completed ‘Project Page’ description
- Demonstrate the author has at least performed a ‘duplicate module’ search
- Have at least a ‘-beta’ release, preferably a ‘-rc’
-
In addition, projects would need to meet ONE of the following triggers:
- Exceed a minimum ‘soak’ period as a –dev module
- Pass a limited peer code review, validating items from #3
- Reach a certain threshold of Drupal sites which report using the module
- Be promoted directly by a community member with appropriate permissions
-
To be considered ‘certified’, projects must meet the following requirements:
- Have an official point release (ie. 1.0)
- Abide by all recommended Drupal Coding standards (though this requirement would be grandfathered for many existing modules)
-
In addition, to be considered 'certified', projects would need to meet ONE of the following triggers
- Undergo a peer review for security, translations, and proper use of Drupal APIs (similar to today’s ‘full project’ reviews).
- Reach a certain threshold of Drupal sites which report using the module, AND exceed a minimum ‘soak’ period with a ‘-rc’ release
- Be promoted directly by a community member with appropriate permissions (theoretically, after a thorough review, but no formal review request necessary)
-
The ‘security team’ would only be responsible for ‘Certified’ projects with point releases. All other project pages would contain a disclaimer, identifying that the project has not been officially certified (and thus has not been reviewed to validate security, proper use of Drupal APIs, compliance with Drupal coding standards, or fitness for use).
-
How the different classes of project are displayed on Drupal.org is not covered in the scope of the proposal, and is left as a future exercise/discussion should the fundamentals of the proposal be accepted as the future direction for project applications.
Comments
looks good
I like the idea that the various hoops are "this or this or this" - makes the whole thing less dependent on slog by humans.
If like me you read through the whole thing, see 'certified' and skip over point 8, read it and re-read it - this does not inherently mean putting any kind of approved marker on project pages or anything like that, the terminology here should just be read as purely internal to the process.
I mostly like this idea as a
I mostly like this idea as a general idea, but I'm not sure it makes sense as something that should be enforced/run via the community process. For the most part we just give people tools and let them use the tools as they want. If they have their own coding standards...that's their choice and I don't think we should create rules around it.
knaddison blog | Morris Animal Foundation
I agree
I knew that piece might be contraversial - and the coding standards checks could certainly be relaxed, given that they are a minor component relative to the rest of the proposal. Personally, I'm a proponent of flexibility (i.e. removing as many requirements/hindrances as possible) ... but given that the coding standards are currently being strictly enforced in the existing project application process (and much more stringently than they need to be!), and they are fairly easy to fix/review, I had left them in for now.
IMHO, the key pieces are i) -dev releases in sandboxes, ii) eliminating the current queue, and iii) enabling multiple avenues of promotion ... If I could trade away the coding standards checks to get these three items, I wouldn't think twice before signing!
Can you validate my assumption that preventing overload for the security team is one of the main motivations for maintaining a proejct application process in the first place (along with general Drupal quality perceptions, of course) ... or is this a false perception that exists within the community?
I think some of the top goals
I think some of the top goals of the process are reducing future effort for security team and infra/webmasters team.
Licensing, duplicates, and inappropriate modules are a big source of additional work for infra/webmasters so we also need to reduce that.
knaddison blog | Morris Animal Foundation
I support this!
I support this (Light Weight) proposal IF it was a light weight purposal. The outline says one thing, the documents seems to say another. The process is too intensive and the statistics of 6-7 week timeline is on the very optimistic side. (Some Modules take 28+ weeks). We need a simplified proposal with simple guidelines (there is also always over 300 items)
--Sig--
Owner of Proper Programming, LLC a software and website development firm.
Can we get some kind of
Can we get some kind of official clarification regarding the coding standards? I've had this conversation with a dozen different people with a dozen different opinions. Some people quote it as law, others don't care, some are in between. There is a lot of "well... you should... maybe... kinda ...I dunno". And, arguments have been started over it. The standards page says, "All new code should follow the current standards, regardless of (core) version."
Not sure there's an 'official' answer
I'm not sure there is an 'official' answer.
Even 'official' docs pages can be edited to include a single person's opinion ... after which anyone who reads the page can grab hold and re-quote that opinion as law.
For myself, I see licensing and security as the number one items which should cause delays in the project approval process. As a reviewer, I also 'encourage' collaborating with existing projects and aligning oneself with the coding standards.
However, my observation has been that a very large number of project applications get caught up in the queue due to module duplication and coding standards discussions ... which contributes to the overall backlog. As this backlog then gets in the way of identifying the actual security/licensing issues (which are supposedly the top priority of the process), and combined with the negative perceptions they leave with new project applicants, my personal conclusion is that the delays caused by 'enforcing' strict module duplication and coding style standards are causing more damage than they are preventing.
As a result, I know that I will be relaxing my personal standard regarding coding style and module duplication going forward.
Don't get me wrong ... coding standards are important ... but if the author chooses to indent four spaces instead of two, I'm likely to still RTBC the application - along with a suggestion that he adopt the 'Drupal way' of doing things. And I'll still be asking how the module differs from similar projects ... but if the author feels that their 'lightweight' version with less external dependencies is a better way of doing things, and it isn't a complete 1 for 1 duplication of function, then I'm more likely to let it through as well.
Statistics
4 Months since d7
- Oldest Review was 4 months old
- Longest response wait: unkown
- Number of Review open issues: 247
- Full Projects - Was not Recorded
8 Months since d7
- Oldest Review: 24 weeks 7 days!
- Longest response wait: 10 weeks 3 days
- Number of Review open issues: 384
- Full Projects - 2214 D7, 5997 d6
Unknowns
- Sandbox Modules - Data not available (can not search sandbox items by Drupal version)
- Number of D6 Modules at 4 Months
- Number of D6 Modules at 8 Months
- Quality of Modules D6 Modules at 4 Months after release
- Quality of Modules D6 Modules at 8 Months after release
- Quality of Modules D7 Modules at 4 Months after release
- Quality of Modules D7 Modules at 8 Months after release
A relative sample of 100 modules of FULL Projects showed
21 were fully maintained and released for drupal 7.
12 were not ported to drupal 6 (also no port planned).
42 were not ported to drupal 7 (also no port planned).
6 are planned to be ported to drupal 7.
46 were abandoned / not maintained for more then one year.
5 were seeking for a new maintainer.
11 were never released (for more then one year).
10 were never leaving dev (for more then one year).
Reference http://groups.drupal.org/node/139754
--Sig--
Owner of Proper Programming, LLC a software and website development firm.
Formal Review verse Natural Review
A simple decision tree and decision example mapping.
A person who is working on Drupal, comes in and installs the latest version (D7), then looks for a module http://drupal.org/project/imagefield_archive They see that only 31 Sites use it. They then look into the issue queue and finds no requests for it to be ported to D7. They Decide to re-write the module from scratch instead of porting an existing module. They wont port it because it seems to be more work then worth it. This is not a fictional story, it played out just like this last night. The person doing this is a veteran of Drupal and has many more years then Me (They where around when D5 was the only version).
Now this person could post their module without a review because they have access to GIT, and have enough Karma too get away with large scale mammal slaughtering. I am not critical of this user, in fact I support their decision to do what they did as I would of done the something. In addition a D5 Amazon module I inherited was succeeded with a D6 version in an identical way! This seems to be a common story for smaller lower maintained modules.
Review Process
1) Module is Added to Sandbox
2) Module owner files a request for GIT access (starting the Review Process)
3) A volunteer assess the module and approves the module (Goto Step 5), or makes suggestions and improvements (Goto Step 4)
4) Module owner fixes module and updates request for GIT access. (Goto Step 3)
5) Module becomes a "full project"
Natural Open Source Review Process
1) Module is added to the module page
2) Module consumer look at the module and issue queue and gathers information regarding the module
3) The Module Works as intended (Process Ends), The module fails to meet expectations (goto step 4)
4) Module consumer decide to search for another module (goto step 2), develops a new module (goto step 1), Files an issue, Patch or feature request, improvement, or writes documentation.
5) Module owner Applies Patch, Makes improvements, or fails to respond.
Review Process Conclusions
The review process is that it takes upto 6 months to release a module from sandbox to module status. Its difficult to finding any sandbox modules (example: when you attempt to search d7 sandbox modules you get 0 results). Installing a sandbox module can require knowledge of GIT which further limits its use. The formal review process is reliant on volunteers. Thus Sand boxing a project limits its exposure to module consumers which lowers the numbers of module consumers and restricts the natural review process.
We CAN conclude that the reviewed projects will certainly be a higher quality then non-reviewed projects. We can conclude that the review process can take up words of 6 months.
Natural Open Source Review Process Conclusions. The Natural Open Source Review Process takes place every time a consumer looks at a module page. The natural review process makes every Drupaler a Module Reviewer. The Consumer is the quality assurance specialist.
Sorry for the duplicate posts, but I think these provide additional resources for decision making
--Sig--
Owner of Proper Programming, LLC a software and website development firm.