The document presents a session on selecting the right Drupal modules, focusing on the R.E.A.D method: Research, Evaluate, Analyze, and Determine. It provides practical steps for Drupal developers to make informed decisions on using contributory, patched, or custom modules, and includes real-world examples to illustrate various scenarios. The speaker, Michael Miles, shares his extensive experience with Drupal and emphasizes the importance of community engagement and coding standards.

1. R.E.A.D
How to select the right modules
https://2015.midcamp.org/node/1106
Florida Drupal Camp 2015
#fldc15

2. Who You Are
New to Drupal.
Want to improve habits.
Session curious.

3. Your Role
A Drupal developer.
A site architect.
Functionality decision maker.

4. What it is all About
How to quickly make smart, informed functionality decisions.

5. What we will Cover
Steps to decide between a contrib, patched or custom module.
Real world examples of R.E.AD
Basics of a patch & Basics of a custom module.

6. Michael Miles
From: Boston, MA
Work: @WeAreGenuine(.com)Genuine
Exp: Working with Drupal since 2008.
Recently named an Acquia M.V.P
Twitter: @mikemiles86 Drupal.org: mikemiles86
All the Places: mikemiles86

7. R.E.A.D
Research what exists.
Evaluate the options.
Analyze the gap.
Determine amount of change.

8. Research What Exists

9. Isolate Keywords
Read documentation, specs, etc...
Pay attention to unique nouns and verbs.
Ask questions!

10. Perform Searches
30k+ Modules available.
Favorite search engine "Drupal [keyword]".
Search on Drupal.org

11. Utilize the Community
Use IRC: #drupal, #drupal­support.
Use Stack Exchange: .
Social Networks: G+, Facebook, LinkedIn.
Even reddit! .
drupal.stackexchange.com
reddit.com/r/drupal

12. Isolate Keywords.
Perform Searches.
Utilize Community.

13. Evaluate the Options

14. Read the Description
What does the module do?
What does the module not do?
What does the module depend on?

15. Community Adoption
Downloads vs. Installs vs. Age.
Activity of issue queue.
Issues are good, not bad!

16. Maintainer Activity
Participate in issue queue?
Accepting of feedback?
Regular commits and/or releases?

17. Read the description.
Check community adoption.
Check maintainer activity.

18. Analyze the Gap

19. Download and Test the Module
Gain a better understanding.
Use a sandbox: .
What is offered out of the box?
simplytest.me

20. Discover Missing Functionality
What does it not do?
Missing 80%? Missing 20%?
Bigger gap = Bigger effort.

21. Check for Community Solutions
Look at the issue queue.
Search "Drupal [module] [functionality]".
Ask questions!

22. Download and test the module.
Discover missing functionality.
Check for comunity solutions.

23. Determine Change

24. Review the Module Code
Does it follow coding standards?
Is it extendable?
Can you figure out what does what?

25. Estimate Effort
How much code to rewrite?
How much code to add?
How much time is there?

26. Extend or Alter
Adding functionality?
Changing functionality?
Changing the modules goal?

27. Review module code.
Estimate effort.
Extend or alter?

29. Examples

30. Scenario #1

31. The Requirements
WHEN SAVING A FILE ENTITY
AND IT IS A JPEG IMAGE
THEN THE EXIF META DATA NEEDS TO BE CAPTURED
AND MAPPED TO CUSTOM FIELDS
AND THESE MAPPINGS NEED TO BE EXPORTABLE USING FEATURES

32. Research What Exists

33. Isolate Keywords
WHEN SAVING A FILE ENTITY
AND IT IS A JPEG IMAGE
THEN THE EXIF META DATA NEEDS TO BE CAPTURED
AND MAPPED TO CUSTOM FIELDS
AND THESE MAPPINGS NEED TO BE EXPORTABLE USING FEATURES

34. Perform Search
We will focus on the keyword "Exif"

35. Search Google

36. Utilize the Community

37. Evaluate the Options
Exif custom seems like best fit.

38. Read the Module Description

39. Look at Community Adoption

40. Look at Maintainer Activity

41. Analyze the Gap

42. Download and Test the Module

43. Discover Missing Functionality

44. Check for Solutions

45. Determine Change

46. Review Code

47. Estimate Effort
Add Features integration.
Alter primary key for mappings.
Time is minimal.

48. Extend or Alter
Adding features support.
Not changing what module does.
Extending.

49. Which Path to Choose
Use module as is.
Patch module.
Write own module.

50. Patch!
Module meets 90% of needs.
Small gap, small effort.
Extends module.

52. What is a Patch?
.
A structured list of changes to files.
Re­appliable to files.
Focused on a single change.
drupal.org/patch

53. Creating a Patch

54. Clone and branch module git repo.

55. Make changes to code.

56. Test your changes.

57. Generate patch file.

58. diff --git a/exif_custom.features.inc b/exif_custom.features.inc
new file mode 100644
index 0000000..243bbe2
--- /dev/null
+++ b/exif_custom.features.inc
@@ -0,0 +1,158 @@
+<?php
+/**
+ * @file
+ * Features file for the exif_custom module.
+ */
+
+/**
+ * Implements hook_features_api().
+ */
+function exif_custom_features_api() {
+ return array(
+ 'exif_custom' => array(
+ 'name' => t('EXIF Custom mappings'),
+ 'default_hook' => 'exif_custom_export_maps',
+ 'feature_source' => TRUE,
+ 'default_file' => FEATURES_DEFAULTS_INCLUDED,
+ 'file' => drupal_get_path('module', 'exif_custom') . '/exif_cus
+ ),
+ );
+}
+...

59. Submitting a Patch

60. Create/comment on issue queue.

61. Attach your patch.
Follow patch naming standards
[module]­[description]­[issue­number]­[comment­number].patch

62. Watch for feedback.

63. Wait for merge. (hopefully)

64. Giving back to the
community

65. Scenario #2

66. The Requirements
WHEN SITE USES WORKBENCH TO MODERATE CONTENT
THEN CAN CREATE MULTIPLE TRANSITIONS BETWEEN STATES
AND TRANSITIONS ARE EXPORTABLE USING FEATURES
WHEN EDITNG A CONTENT REVISION
THEN CAN SCHEDULE A TRANSITION
AND CAN SELECT DATE FOR FIRST STATE
AND CAN SELECT DATE FOR SECOND STATE

67. Research What Exists

68. Isolate Keywords
WHEN SITE USES WORKBENCH TO MODERATE CONTENT
THEN CAN CREATE MULTIPLE TRANSITIONS BETWEEN STATES
AND TRANSITIONS ARE EXPORTABLE USING FEATURES
WHEN EDITNG A CONTENT REVISION
THEN CAN SCHEDULE A TRANSITION
AND CAN SELECT DATE FOR FIRST STATE
AND CAN SELECT DATE FOR SECOND STATE

69. Search for Existing Modules
We will focus on the keywords "workbench schedule"

70. Search Drupal

71. Evaluate the Options
Look at Scheduler Workbench Integration.

72. Read the Module Description

73. Look at Community Adoption

74. Look at Maintainer Activity

75. Analyze the Gap

76. Download and Test the Module

77. Discover Missing Functionality
Unable to create different transitions per type.
Unable to select per revision.
No features support.

78. Determine Change

79. Review Code

80. Estimate Effort
Refactor creating schedules & transitions.
Decouple transitions from content types.
Add Features integration.
Will take time.

81. Extend or Alter
Changing how transitions/schedules are created.
Changing purpose of module.
Altering.

82. Which path to choose?
Use module as is.
Patch module.
Write own module.

83. Build a custom module!
Too big/complicated to be a patch.
Would alter module goals.
No other module exists to support use cases.

85. Writing a Module
.
Follow Drupal coding standards.
Make use of hooks and APIs.
Test your code!
drupal.org/developing/modules

86. Contributing a Module
Ask yourself:
Could others use this?
Seriously, is it abstracted enough?

87. Name module appropriately.
Namespace based on dependencies.
Be clear, not clever.
Should indicate what module does.

89. Provide a detailed description.
Explain what module does and does not do.
Outline any dependencies.
Help fellow R.E.A.D­ers.

91. Be a good maintainer.
Bugs are badges not bruises.
Participate in the issue queue.
Update, release and improve.

93. Let's review

94. Remember to R.E.A.D
Research what exists.
Evaluate the options.
Analyze the gap.
Determine amount of change.

95. Slides & Notes
bit.ly/fldcREAD
bit.ly/fldcREADslides
bit.ly/drupalREAD

96. Feedback
@mikemiles86
#fldc15

97. #fldc15 R.E.A.D / Michael Miles
Thank You!