Drupal

Context UI did not show up at all.
Enabled Context Layouts, and Context UI showed up, but reportedly without the ability to add blocks as reactions.
Cache cleared all with Drush, and Context's UI disappeared again.
Disabled Context Layouts, and it came back and everything seemed to work, at least momentarily.

This does not remotely exist yet. Funding a point person to lead the project to make it, and creating or improving all the modules that would make it up, is a job for coordinating community initiatives- itself an initiative that could use support.

Brand new module using the Migrate module: http://drupal.org/project/typo3_migrate

Links to other attempts and case studies:
http://drupal.org/node/219495

All answers and thoughts on this thread:
https://community.openatrium.com/issues/node/48

i chose: http://project.grayside.org/atrium/project/atrium-group-tools

Agaric wants Drupal-native (or Redmine/Chiliproject) checklist storage, sharing, and use for things like the not-yet-ultimate web site development and deployment checklist.

The Drupal 7 road map of Checklist module looks very helpful but it is moving slowly.

The ability to have tasks link to how-tos, to be able to share and re-use lists, with user or project-specific tweaks, would be fantastic.

Sometimes you want content that is still managed by a content management system, but not displayed with any of the blocks or menus or anything else the CMS usually helpfully supplies. You may even want to take over the content definition or other information sent with the page but not seen. In other words, Take over entire page with HTML/XML defined in content.

Is there a module yet to allow a piece of content to completely take over a page? Defining all the headers and HTML and XML with nothing generated by Drupal?

Having experienced writing an epic tech book - 36 authors and 36 chapters and no, it did not break down nice and neat like that - we are convinced there is a better way than the traditional publishing model. Drawing on the tradition of open source free software about which we wrote, we propose donation-funded, completely free and open texts of superior quality and timeliness, marked by clean mark-up and powered by technologies of collaboration.

Messages to AJAXify with a helper module to http://drupal.org/project/formmsgs

Error messages to AJAXify-- why wait until you submit the form to know this?

The first ones are relevant
* "The username cannot contain multiple spaces in a row."
* username taken (both these handled by http://drupal.org/project/username_check )
* optional duplicate title warning

Nor is this export necessarily for the commonly accepted need to export the configuration of entities' bundles and their fields (although, to make things more confusing, fago's main use case is to make bundle definitions into entities)

If two messages apply to one form element, then both apply.

A multivalue form ID field.

Also ideally, that export would live only in code if the UI were never needed. On this point, unfortunately, Entity API always automatically imports to the database, rather than reading from code at runtime.

Seriously, Drupal, what the hell?

This code is the callback for an #ajax property on a form element. The HTML returned replaces the HTML provided. That all works. What gets tricky is the form validation function being called and getting the error.