Presented by Eric Goldhagen

• Actions and Triggers - ways of creating automated functions (actions) when a certain condition is met (trigger)
• Without writing code to refine what the trigger was, couldn’t get specific enough
• Rules module gives more fine-grained control through the web interface (e.g. when someone creates a node of type x, send an email with this specific text to users of y role.)
• As with Views, it looks like Rules will be widely adopted because module developers are hooking into Rules or exposing their modules to Rules

Looking at Rules

• You can import and export rules, put rules into a module or features to store it as code under revision control
• “Content is going to be saved” event - when content is being added to or updated, happens in that moment in between hitting save/submit and it actually being updated
• (watched a demo of a rule being set up)
• There is more than just AND logic available for Rules; can configure OR and ELSE as well
• Performance issues are present; best way to avoid them is to put your most important condition at the very top, e.g. if a rule only applies to members of a certain role, put role membership check is happening as early as possible so the other steps don’t have to run

Presented by Frank Carey (frankcarey)

• In the beginning, Drupal was very code centric
• if you wanted to make something you coded a module, relied in hooks API, etc
• Content ruled the land (the database), but modules still stored many settings in the database
• Content in Drupal - nodes, friends, comments, votes, users, messages
• Then came the GUI-la Monsters - Flexinode, Views, CCK, Contemplate, Rules, Context - things you’d normally do with code, but now could do through the UI
• Config settings include variables, CCK, permissions, views, contexts, panels, blocks, and rules
• Why should this stuff be in code and not the DB?
  • How do you track changes within the database?
  • How do you revert back when you make a mistake?
  • How do you reuse configurations?
  • How can you work as a team?
  • How can you update settings across sites?
• If your settings/config are in code, you can use version control to handle those thing
  • take your pick, but pick something! CVS (going out of use though), Subversion, Git, Bazzar, Mercurial
• How do we get stuff into code?
  • Some modules provide their own custom export and import functionality - views migrate rules
  • some are leveraging ctools export api (paenls, context, etc)
  • some are adding exportables to other modules or tables (Input Formats and Strongarm)

Ctools exportables

• Tool attempts to solve the common problem of handling exportables.
  • Defining exportables structure
  • Getting the data from the DB and creating the xportable object
  • importing the data from either db or code
• Ctools exportables
  • Need a persistent, unique identifier in the table that contains the object you want to export (the machine name)
  • Implement a few lines into hook_schema() or hook_schema_alter() to get ctools functionality
• So what the heck is Features?
  • Features is basically an exportables manager
  • It creates “features” modules, which are really just normal modules (features is not a hard dependency
  • allows for a gui interface to choose what things you want to export per feature
  • it provides drush integration to easily update and revert changes from the CLI
• What should a feature consist of?
  • Look for logical sections and atomic functionality
  • Examples: Blog, Gallery, Users, Content Type X - these are features on the site that are comprised of content types, views, blocks, etc that come together to create one complete feature on your site
  • Can be traditional code as well: stuff that used to go in helper modules, additional theming, etc. All of Drupal’s hooks are available to Features.

• In the beginning, Drupal was very code centric
• if you wanted to make something you coded a module, relied in hooks API, etc
• Content ruled the land (the database), but modules still stored many settings in the database
• Content in Drupal - nodes, friends, comments, votes, users, messages
• Then came the GUI-la Monsters - Flexinode, Views, CCK, Contemplate, Rules, Context - things you’d normally do with code, but now could do through the UI
• Config settings include variables, CCK, permissions, views, contexts, panels, blocks, and rules
• Why should this stuff be in code and not the DB?
  • How do you track changes within the database?
  • How do you revert back when you make a mistake?
  • How do you reuse configurations?
  • How can you work as a team?
  • How can you update settings across sites?
• If your settings/config are in code, you can use version control to handle those thing
  • take your pick, but pick something! CVS (going out of use though), Subversion, Git, Bazzar, Mercurial
• How do we get stuff into code?
  • Some modules provide their own custom export and import functionality - views migrate rules
  • some are leveraging ctools export api (paenls, context, etc)
  • some are adding exportables to other modules or tables (Input Formats and Strongarm)

Ctools exportables

• Tool attempts to solve the common problem of handling exportables.
  • Defining exportables structure
  • Getting the data from the DB and creating the xportable object
  • importing the data from either db or code
• Ctools exportables
  • Need a persistent, unique identifier in the table that contains the object you want to export (the machine name)
  • Implement a few lines into hook_schema() or hook_schema_alter() to get ctools functionality
• So what the heck is Features?
  • Features is basically an exportables manager
  • It creates “features” modules, which are really just normal modules (features is not a hard dependency
  • allows for a gui interface to choose what things you want to export per feature
  • it provides drush integration to easily update and revert changes from the CLI
• What should a feature consist of?
  • Look for logical sections and atomic functionality
  • Examples: Blog, Gallery, Users, Content Type X - these are features on the site that are comprised of content types, views, blocks, etc that come together to create one complete feature on your site
  • Can be traditional code as well: stuff that used to go in helper modules, additional theming, etc. All of Drupal’s hooks are available to Features.

Notes from Features Demo

• When you look at your list of features with diff module enabled, you can see how a feature has been overridden within the current configuration
• Turning on Strongarm allows you to export variables (from the variables table) into a feature

Command-line features

• Features exposes many commands to Drush that can then be used from the command line
• features revert - revert a feature from the command line; this reverts changes made within the UI to settings that you’ve configured within a feature

Features/Exportable Gotchas

• Some exportables can’t be exported more than once (e.g. can’t re-export a default view)
• Features-revert-all can be dangerous, blow away work
• Not everything is exportable yet
• Revert-all doesn’t work if there’s no diff (fixed recently in dev)
• Dependencies can be tricky.

Developments to watch out for

• Better core exportability in Drupal 8
• Use of UUIDs as unique IDs
• More end-product modules that implement a fully featured user experience
• hook_features_alter() - allow partial overrides that are exportable as well
• Easy Features = Better Install Profiles

Additional Things to See

• http://drupal.org/project/features
• All features enabled modules

Random/Framing Notes

• Introduction to HTML 5 book is a primary reference during this conversation
• Is it a good ideal to add a bunch more options, fields, and decisions for what to HTML5ize or not throughout Drupal? This might create some big UI/UX problems.
• Might be better to have all Semantic HTML5 settings on one big page, rather than have the configuration distributed throughout Drupal
• Doing all the config in one place will also give us a really easy way to set all the defaults more manageable.
• However, having all the config in one place AWAY from the creation/edit pages for these entities could be cumbersome
• Can we have the same settings in two places? The Semantic HTML5 module settings page AND the individual settings pages for menus, blocks, etc?
• We’re going to start out in Drupal 6, it’ll be difficult and messy, but we’ll learn as we go and then know how to tackle this in Drupal 7
• If we build an API for this and collaborate with creators of Semantic Views, Semantic CCK, Mothership, etc, might be a great way to go for Drupal 7
• Might never be an API because in Drupal 7 this is going to be done by drupal_render
• We’ll need to include JavaScript to include semantic tags on non-HTML5 compliant browsers
• Our goal is to make Drupal work for HTML5, not to make HTML5 work in all web browsers

Forms and Fields

• Form API gives us a big advantage and many abilities to make changes to any form field
• right now we can primarily work with core and CCK fields
• we can provide support moving forward, but we can’t completely anticipate what other fields will be used for; we can’t inspect backwards
• we can also work with modules like Date, Email
• use the Elements allows module developers to use Form API to get HTML5 form elements into their modules; a separate module would be used to transform core and CCK fields to HTML5 elements
• want to be able to switch fields from “text” field to “email” field; Elements module lets you do some of that already
• we’d need a different module that does what Elements does to core fields
• other things to support with the other module - search (core)
• these modules will override the markup for CCK widgets
• we need to figure out how to override markup for all the fields with HTML5 elements; then we need to figure out how to implement that within the module, allow people to specify which fields they want to override, etc.
• Could also consider getting this stuff into modules (CCK, Date, etc) themselves anyhow to avoid having to develop an entirely separate module

$header and DOCTYPE

• DOCTYPE has to be changed but that’s relatively easy
• Header elements are also done differently in HTML5
• In Drupal, $header is spit out by Drupal
• In Drupal 6, $header is populated by both core and by the drupal_set_html_head function - anything can be put into the $header using that function
• We can tackle this on the module level, but would then need to ensure that the module gets executed last (and other modules are already jockeying for that position)
• In Drupal 7 what you’re adding to headers is much more structure
• Other option - handle it at the theme level using a preprocess function - wind up with an amorphous blob of text that we could regex to replace tags with HTML5, but it’s not foolproof
• A module seems like a headache; a starting point in a base theme might be a better way to go
• If an edge case uses the old HTML ways, the page/site will still work
• If this is done with a module, anyone can do their own HTML5 theme, $header is still printed normally, instead what you get out of $header is now HTML5 instead of the old way to do it
• drupal_add_http_header and drupal_add_html_head are used in Drupal 7, so getting stuff into $header will be much more structured
• We could backport that from Drupal 7, but contrib modules might not work with that backport
• We could implement the backport and append on whatever else was set in the header that isn’t handled by the backport at the end, though that could result in double info
• Are there concerns about the order of tags in the header? Probably tags that have to come after everything else will be appended on the theme layer anyway, and if not it would work if we appended things at the end of the D7-backported $header
• Agreement is coming in this discussion that this should be done in the module level; create a wrapper function that overrides drupal_set_html_head and is a backport of what’s in Drupal 7; modules can use our function if they provide needed information that they want in the header; and if any modules are not using our function to set header tags those are just appended at the end of the $header
• possible module names: HTML5 API, HTML5 tools
• might have implications for limitations on script and styles tags (e.g. IE limitation of number of CSS files)
• The syntax has only been simplified in HTML5, but how do we get in there and alter those variables?

Document Layout Tags

• The new HTML5 document layout tags include article, header, footer, nav
• Much of this is a theming layer issue
• A group needs to get together, figure out best practices, and rewrite node.tpl.php and page.tpl.php for a base D6 theme
• However, some tags come out of core, CCK, and Views
• Some of the HTML that core spits out has theme functions, some doesn’t (e.g. comments)
• We can create a theme function that rewrites and fixes core HTML that doesn’t already have a theme function
• Mothership theme might be a good place to look for existing fixes or a list of possible problems to look at
• Views and CCK - do we fix Views and CCK, or do we tell people to use Semantic Views and Semantic CCK instead?
• Can we wrap our solutions up as Features, perhaps including Semantic Views and Semantic CCK
• One possibility - require Semantic Views and Semantic CCK modules as part of this feature, add a lot of HTML5 documentation to the top of the Semantic CCK form (and Semantic Views too?). We should also prepopulate as many predictable HTML5 settings in Semantic CCK and Views as possible, just like what happens in Semantic Views and Semantic CCK already; in both we’ll be using HTML5 markup.

Menus and other Drupal entities

• there’s a nav tag in HTML5
• Not every menu is a nav, but there are some we know are navs, e.g. primary links and secondary links
• Stuff that only shows up for administrators are second-tier issues for us
• there is some debate about what menus might qualify as navs and what might not
• consider creating a Semantic Menus module
• Though we’re not sure of the way we’ll do it, we do have a goal of altering the menu creation form so that a user can choose to make a menu HTML5 or not
• Other Drupal entities that we need to tackle similarly: blocks, comments
• Config page for the module(s) we create could turn HTML5ing on for particular entities; turning HTML5 on for those entities will turn on

Presented by Robert Holmes (robbiethegeek)

(Got here a bit late, but caught the very beginning of drush command overview)

Handy drush commands

• drush - listing of all the drush commands available to you
• drush status - basic info on your site
• drush sqlc (drush sql-cli) - takes you into MySQL console using the credentials of the site you’re accessing with drush right now
• drush dl <projectname> - downloads code for module (project) into sites/all/<projectname>; can list multiple projects at once
• drush dl <projectname>-<version> - download a specific version of a module, e.g. drush dl filefield-6.x-3.x-dev
• drush en <projectname> - enable <projectname>
• drush up - upgrade code and database for Drupal core and third-party modules
• drush sql-dump - Performs a dump of the current Drupal site’s database. This will vomit it all over the screen, so instead you’ll want to direct the SQL dump to a file using drush sql-dump –result-file=filename.sql or drush sql-dump > filename.sql (and then
• drush cc - clear the cache that you then specify from the menu, or specify within the command as drush cc theme or drush cc all etc
• drush help <command> - get help on the given drush command

Random Notes

• You can use drush in conjunction with other shell commands, wrap drush commands in shell scripts, etc
• Other modules can also expose functionality and add commands to drush, e.g. devel module
• Drush supports the ability to remotely connect to a server - open an ssh connection, run a drush command, and bring it locally
• http://dgo.to/ - Drupal URL shortener AND smartener with quick paths to projects, issue queues, nodes by number, users, etc

Presented by Roger López (zroger)

Admin Themes

• clients/users appreciate a clear visual division between the public front-end view of the site and the admin view
• Garland: out-of-the-box theme that can be used to easily create that visual separation; it’s the easy choice, but there are others that are specifically tailored to be admin themes
• Root Candy: specifically focused on being used on the administrative side; creates tabs at the tops for “root-level” admin items, emphasis on readibility, good table structures
• comes with built-in slide-out control panel that you can drop any block on the site into
• Rubik: another admin theme designed for clear, clean admin with a keen eye to styling messaging, help text

Tools, Toolbars

• Admin module; little wrench in the corner that expands out into an administration
• admin_menu module: gives you a nice dropdown menu across the top of your site (front-end and back-end), a number of functions under the Druplicon dropdown menu

Administrator != Developer

• A menu of quick-links specially created for client administrator can be very helpful
• Modules to build an admin interface:
• Views bulk operations - lets you build a view of content (eg nodes, files, comments) and provide checkbox-style operations on all of the nodes
• Draggable Views - lets users drag and drop lists of content into a completely arbitrary sort
• Nodequeue - one step beyond Draggable Views, does the drag and drop sorting but also controls specific pinpointing of what content is included in what queue, e.g. take ten completely unrelated nodes and put them into one queue
• Panels - you can use it to create a dashboard view of content for your administrators, e.g. a dashboard just for users who are comment moderators

Developer tools & APIs

• Ctools - suite of modules that exist to support other modules
  • includes AJAX library - ideas behind it are foundation for AJAX libraries in Drupal 7
  • Wizard - multi-step forms
  • Non-volatile Object Caching
• Dialog API - merges jQuery UI Dialog widget with Ctools AJAX - do simple form submissions through a dialog
• Features - bundle up all the views for admin interfaces, just like with the front-end stuff

WYSIWYG

• they’ve gotten better at outputting valid (if not entirely efficient) output
• WYSIWYG API is the way to go now; editor specific modules are deprecated
• input_formats - new module that allows you to export input formats as Features code (!!!)
• better_formats - module that attempts to improve the input format specifications of Drupal, default input formats per role (!!!)
• Insert - works in conjunction with imagefields and filefields - get an insert button next to each imagefield, throws it into the body of the node, works with all major Imagefields (!!!)

Random

• Check out http://www.sequelpro.com/ - MySQL management for Mac OS X

Presented by Theresa Summa (theresaanna) and Seth Cohn (sethcohn)

• Looked at a non-Drupal site, cnn.com - cramming as much information on one page as possible - they throw as much on the page as possible to appeal to as many different people as possible
• observer.com - a Drupal site that does something very similar
• How do you standardize the display of each piece of content on your site (e.g. pictures in proper sizes, providing all essential data, formatting it)
• economist.com and globalpost.com - more content-rich sites built in Drupal

Imagefield

• let users upload images in a CCK node
• lets users upload multiple images, sort the list to select which is going to be featured on the front page, the others get inserted into the content appropriately and in a consistent way by Drupal
• bulk uploader available

Imagecache

• resizes/crops images on the fly according to your preset dimensions
• helps standardize image sizes across the site
• Imagecache is included in Drupal 7 core, hurrah!
• Imagecache presets stop large images from breaking your layout

Quicktabs

• allows you to combine multiple items into one Quicktabs block with tabs on the top
• Nice jQuery action to allow users to switch from one section to the next, loaded all at once, or via Ajax on the fly
• Plays nicely with Views, individual Nodes, and multiple Blocks

Views Slideshow

• the recommended solution (”best of the breed” according to Seth) for rotating carousel type things

Panels

• Provides a drag and drop interface for units of content on the site to be added, deleted, and arranged in a layout on the fly
• “is all sorts of insane magic”
• pros for Panels - great Views integration, user friendly for non-techie users
• Negative - spans between modules and theme layer, so it’s slower, performance hit on your site, takes a lot of liberties
• If you’re a themer, you might be able to do without panels

Composite Layout

• could be called Panels Light
• gives you the Panels approach but does it on a node by node basis - you can choose predesigned layouts on a node by node basis, e.g. a different layout for each individual blog entry, on the fly.
• Display Suite is another alternative

Vertical Tabs

• for the content adding and editing side of the site - much easier
• divide your node add/edit forms into sections with vertical tabs on the side, collapsed along with a summary of the collapsed settings.
• Makes large content types easier for content producers to maintain
• Drupal 7 includes this in core, Drupal 6 module mostly works well

Arrange Fields

• http://drupal.org/project/arrange_fields
• First commit was 5 weeks ago as of 7/24/10 so is early on, but lots of potential
• “This module lets you drag-and-drop the fields of any CCK content type, Webform, or almost any other form in Drupal into the positions you would like for editing. This makes it super simple to have forms with inline fields, which you can change at any point. Tab indexing is also updated, so no matter how you arrange the fields, the users can still tab through them easily. And, you can now add arbitrary bits of HTML markup– labels, images, HR’s, etc.”

CCK Fieldgroup Tabs

• separate CCK fields onto a completely separate tab to break down long node creation forms

Random Notes

• check out Nodequeue again for arbitrary lists of nodes, drag and drop
• you can feed Nodequeues through views
• Imagefield Insert module
• get good at Views theming - so much can be done!
• My question: what’s the best practices approach to fine-grain tuning of everything via node-whatever.tpl.php files vs doing as much as possible within the CSS. Answer: there are a lot of different philosophies; have to consider how custom and how specific this content type needs to be displayed. If it can be done through CSS fairly easily, go for it; there’s a performance hit to loading bunches of node-whatever.tpl.php vs using already loaded & cached CSS. Theresa says her philosophy is to keep the number of files down as much as possible.
• Omega theme (Theresa: “If Zen and 960gs had a baby, it would be Omega”

Civi Updates & Announcements:

• first public alpha this Friday, code is pretty stable
• good changes in UI, features, functions
• CiviCRM book is “officially” coming out after book sprint in April, though it’s already up on en.flossmanuals.net - it’s bigger than Harry Potter! Includes broken out sections with step-by-step guides for everyday tasks
• Check out http://civicrm.org/groups/nyc for more info on the meetup group
• DrupalCampNYC 8 - coming up in July, already 2/3 sold out after one day! http://groups.drupal.org/nyc

Case Study: Phillip Bien - NYS Coalition of Social Workers

• NYS Coalition of Social Workers - formed by a handful of social workers to work directly at teh legislative level
• needed a new website to support advocacy costs, needed raise cash to do effective work to change the laws
• needed powerful professional website, membership benefits & incentives to join - all on a shoestring budget
• CiviCRM 3.1.3, Drupal 6, Dreamhost Private Server (LAMP) with PayPal
• wanted to build a longterm solution
• needed lower fees than a managed SaaS
• open source, strong track record
• Drupal ACL based on membership, abundant Drupal modules, CiviCRM better & better
• current site features: public site, memberships join and create site login, permissioned content types, downloads & docs archive, register for events, self-service contact info updating
• using entirely out of the box solutions for membership, events, etc
• Drupal modules in use: CiviCRM, CiviMember Roles Sync, CCk, content permissions, filefield, text, color, help, taxonomy, pathauto, string overrides, google analytics, views, views UI
• You could do this all without Terminal/CLI, cash, php, html, css, but you should get some help if you can!
• Future: want classified ads, membership cards, CiviMail, member and nonmember pricing for events and purchases, find someone else to work on the site, expire memberships on the first of the month instead of 365 days after join date
• Accomplishments: their legislation is on the Gov’s desk for signature, got lots of new paid members, love the new site for aesthetics, ease of use for site visitors, org members, and administrators
• “NYC CiviCRM meetup provided critical direction to pull this off”

CiviCase Overview and Demo

• track interactions between your organization and constituents
• related to activities built into CiviCRM constituents
• CiviCase ties activities together to create work flows for activities related to constituents
• can create rigorous workflows with requirements for what needs to be done by whom in order to close a case
• good example of a feature developed for a particular group’s needs and contributed back to the larger Civi community
• Right now there is no UI; need to configure an XML file to set up CiviCase, though there’s good documentation online
• You can write import/export interfaces to import anything into CiviCRM, so case information can probably be imported (e.g. from Act) though entire cases can’t be exported from Civi
• Rayogram created email inbox processing script to parse and create new cases in CiviCase via email
• Cases are made up of individual activities in relation to a CiviCRM contact
• When you open a case for a contact, you can describe the details of the case, assign a subject, select a case type, set a status, and create a start date and duration
• opening and closing a case is an activity; you then create new activities within the case
• Jack’s thoughts about specific use cases for clients: CiviCase for grant application processes? safe space cultivation? pen pals?

CiviRelate

• created by FatherShawn
• Drupal module that allows logged-in users to create relationships to a new Civi contacts when they enter that new contact’s information through a profile
• First using CiviRegister, another Drupal module which allows someone to fill out a Civi profile and create a Drupal login at the same time
• Does a dupe check and merge for the contact being entered
• Shawn used Coder to check his code
• module is currently in the Drupal.org CVS queue, but in the meantime you can find it on the CiviCRM wiki

Random Notes

• Check out Boost module for sending an entire Drupal site to static pages that are presented to anonymous users

What is a module?

• allows you to extend Drupal without touching Drupal core code
• wraps related code into packages that can be used in other projects or shared with the entire community
• allows collaboration with the community with common standards

Different types of modules

• Glue modules: put little changes that you need to make to the way that Drupal is processed - not things shared on d.o, but created to achieve specific small things on particular site(s)
• Input filters: take input from users and convert them into something more fantastic (e.g. PHP Filter, Markdown)
• Module plugins: extend established modules that have their own APIs (e.g. Filefield, Views Custom Field)
• Utilities: provide tools for other modules (e.g. token)
• Navigation (e.g. admin menu, teleport)
• Administration (e.g. Admin Menu, Dashboard)

What to ask yourself before you start coding one

• Why am I doing this? Is it really needed? Are you just scared of looking for other modules, installing them, and still not getting what you want?
• Reasons to conquer fear-driven module creation:

1. Time is important
2. Forks suck - can’t split resources, dev time, user base with multiple solutions
3. Your reputation is at stake - people will call you on duplicating existing modules

• Reduce risk progressively. You can’t know everything about every project out there, but every time you think you need custom code, do this first:

1. Do a Google site search of Drupal.org to try to find something that does what you want to do
2. Start talking to real people on Drupal User Groups, groups.drupal.org, and IRC to see if they know of an existing solution.
3. Install a few modules and play with them, exhaust what they can do so you can learn more and more about existent tools
4. Grep an entire contrib repository for what you might need

A few more things before you start…

• Assume your code will be shared and follow Drupal coding standards
• Negotiate the time you’re going to put into this - make sure you have enough time to make it look good!

Methods for starting

• Gut (copy and empty) another module
• Frankenstein (copy and paste from other modules)
• Cheat (use templates)
• Ninja (compose from scratch/memory)

Let’s pick a name

• Check out contrib from CVS and scroll to make sure your name doesn’t exist
• Or do a Google search of Drupal.org
• You’re going to be using the module name in all of your functions, so choose your name accordingly (not too long, not too funky)
• Using module name in core files, so keep it short
• Use all lower case letters and underscores rather than dashes

Start building

• Put your module in /sites/all/modules
• create .info file in your folder; your module will now show up in admin/build/modules
• create .module file in your folder; when you enable your module, code in there will execute
• Add other files to your module: JS, CSS, and module broken down into .inc files if necessary

How do modules add or extend functionality?

• Through hooks, which hook in processes
• You don’t need to start from scratch because of hooks
• Example Goal: redirect user to appropriate taxonomy term page after submitting a recipe. To do this we’ll use hook_form_alter(), use the Devel module, and Drupal API reference.
• Form API - simplifies working with forms. Forms described consistently as PHP arrays, have control over access, validation, and submission, and provide added security

Demo, watched but did not take notes

Changes in Drupal 7

Breakout conversation: CiviCRM and the Drupal Community

notes started partway into the conversation

• How does a person contribute in bite-sized chunks to a code base that is monolithic?
• You can write Drupal modules for CiviCRM - that’s the best way to extend CiviCRM and is a recent development with added hook support
• Drupal has Form API, CiviCRM has Quick Form - you have to be willing to make that leap and learn something new
• there’s a big gap between the users and the developers
• there seems to be a Drupal/CiviCRM PR problem
• CiviCRM can either be broken down into smaller modules are not; just have to make a strong decision and stand behind it.
• Need to put projects out there that’s well defined for people to work on. Give people more concrete ways to get involved. Give specific points of contact for the work.
• CiviCRM is changing. In recent years the concepts of components have appeared, making things more modular; the API and hooks are better developed
• The thoughts that are going on internal to CiviCRM developers that might please Drupal folks need to be publicized better
• Thoughts about having Minimal and Standard installations (maybe Custom too) similar to Drupal 7 installation
• Could have a packged up Drupal/CiviCRM installation to make things easier
• more training videos and materials
• aesthetic differences between Drupal and CiviCRM can also be challenging when going from the former to the latter
• Large CSS and templates cleanup is underway for CiviCRM
• idea to develop a guide to CiviCRM for Drupal developers to ease transition, point out parallels
• modularize WYSIWYG so that people can choose to either use CiviCRM-bundled WYSIWYG or Drupal WYSIWYG API module

There were about 12 participants in the conversation; folks who were here and who were not are encouraged to add their thoughts, fill out these notes, say “I was there,” etc!

(notes starting partway into the session)

• There’s an opportunity to grow Drupal if we can start to get at the diversity conversation
• definition of Drupal community is problematic - very technical requirements, but there’s a vast community that aren’t people who aren’t on D.o or have cvs accounts, implementers and users. Developer-centric approach is limiting. Rise of “themer pride” and project management props makes a difference.
• The “do-ocracy” is so spread out that there’s never going to be a technical definition of degree of participation in Drupal; makes it easier to inherit biases in society
• Power is still based on very developer centric values, e.g. webchick was nominated to make the LGBTQI g.d.o group because she wouldn’t get messed with because of her high stature as a dev in the community
• in any community it’s important to create a sense of openness - not just inclusiveness but many paths to involvement, recognize importance of other roles that extend platform to a broader audience
• primary problem of Drupal community is creating a platform that is usable, extensible, etc - this problem benefits from a diversity of perspectives on all levels, will result in better solutions
• there’s definitely “#notadeveloper” scoffing attitude in the community
• Drupal as an entity is not in the position of building on-ramps. While within the community there are real tensions along lines of identity and privilege - same as larger society - don’t see a specific on ramp barrier to people with lack of privilege
• do-ocracy isn’t a problem when
• problem is who’s going to do anything about this? Drupal Association is the only official entity, could they espouse values of diversity, inclusion, non-discrimination and “enforce” by vocally disapproving when things like the image on the Drupal Card Game goes down
• class is another big vector of power and privilege, but not always as visible a marker as race/gender/sexuality - might be a foothold
• we might have more success with stopping nasty things (i.e. sexist comments/images) from happening than trying to get buy-in for proactive diversity
• what’s the process for handling when “bad things” go down in the community? what recourse to people have if things are going on in the community that are outside of the spirit of Drupal?
• there has to be individual accountability
• some distrust of looking to higher authorities for enforcement
• is it possible to charter local groups?
• false notion that safe spaces organized within Drupal Community like groups.drupal.org will not actually result in better technical products, code, etc
• demonstrating ability for Drupal to be more accessible, egalitarian, open is important
• q: have people ever recruited others to Drupal, especially others who don’t look like others in Drupal?
• a: HopeFoundry - taught non-programmers Drupal, 1/3 of them are becoming active with Drupal, some of them have provocative stories that need to be told, a model that can be replicated. Do it at an application level, you can choose to be diverse
• “Drupal = a big building with no doors on the ground floor; if you go around back and up the stairs to the IRC channel you can find a way in”
• In any community, the most influential people are the most invested. As communities grow the core group starts to expand as well. Community can occur organically if more people buy in and do something about it, build on-ramps to Drupal, on small-scale/individual levels, makes the community evolve.
• Do we feel comfortable bringing people in to Drupal who are not part of the majority/privileged classes in Drupal?
• Bringing people like me (in this case queer, poc, politically left) would not go so well, afraid they’d just get pissed and never come back
• Some people are activated by getting pissed off, some people are turned away - they deal with this throughout their lives, don’t want to deal with this
• Encouragement for people to write blog posts, public thoughts on what we discussed here, get it out there
• The people in the room have it in us to change things
• Focus on ground up, grassroots response and action on these issues
• We need more models for training and curriculum to bring more, different people into Drupal