planning

We now have a testing framework in Drupal core. What we need to move forward is some structure that makes writing tests easy and efficient so that we can go towards our 100% code coverage goal without wasting development resources.

What would you like to see happen for a 'first' step? Some additional postings/discussions here on the group? A live chat of some kind? An actual in-person meeting? If so, would it just be to get to know each other or perhaps some kind of show-and-tell? What do you think we should do?

Do you have something you want to learn in an upcoming meetup, knowledge you would like to share, cool ideas, or suggestions? Post your thoughts here and we'll try to integrate them into the next meetup. I'll make sure to stay on top of this thread though it may get pushed down over the course of the month.

Here are a few suggestions from a previous post to get us started. I've added some comments in brackets.

I am right now planning the drawing API. Since you, developers are the ones who will primarily use this API, I decided to do this outlining publicly. If you have any comments, ideas of how you would find it easier to use later on, please share it, and if its well founded, i will do my best to incorporate it into the module.

Drawing API in shape of the Forms API

Flexinode still has potential. A lot.
I started off with, what I beleive to be the Perfect Normalised Usable, yet Simple fields system. I posted the ERD and some notes on my website. We should get that somehow into some wiki, to create the Ultimate Architecture and Plan.

I posted a recent flexinode update on my blog. Please read that, to see where we are now and where we are heading.

The most important part from that post is:

1. First we must clean out all the code and remove broken fields.
2. Then fix all critical bugs.
3. Then fix the upgrade path from 4.6 to 4.7.
4. Once stable, a 4.7-2.0 release will be brought out. and a 5.0 branch is opened.
5. Then I will start committing patches to prepare for a 5.0 release.
6. Once stable, a 5.0-1.0 release will be brought out.
7. Then new features make a chance o

During our IRC meeting and phone call we came to the following list of action items:

• Define Relationships via a common API – crunchywelch
define_relationship(nid = INT, uid = INT, status_flag = STR, module_name = STR);
retrieve_relationships(array(nid = INT, uid = INT, status_flag = STR, module_name = STR));
retrieve_relationships(array(nid = ARRAY, uid = ARRAY, status_flag = ARRAY, module_name = ARRAY)); ?
retrieve_relationship(rid);
        – statusflag value = string defined within module
• Mail UI – drob – check-in with Amazon and the folks working on mail
• Mail API – drob – check-in with Amazon and the folks working on mail
• Use Cases on groups.drupal.org – drob to put up his UC titles for others comments
• Librarian - ?? - drob thought it a good idea to have a committed Librarian for all things events - however no-one volunteered
• Theme and/or helper functions that modules can use to help with theming - grugnog

Duplicated from my reply to Marketing Offensive at Drupal.org: http://drupal.org/node/59170#comment-112184

I think the reason Mozilla was so successful was because they had a well planned approach resulting in a unified and focused effort. Prior to building a campaign, a company (eg: Drupal.org) will create a "Communications Strategy" which is then passed to the Advertising Firm (eg: Drupal Community). The following is an outline for a Communications Strategy:

1) Why are we doing this campaign, what are the goals?
2) What message are we trying to communicate?
- a) What is the product benefit?