core

there were quite a few people that wanted to get involved but just didn't know where to do so, they didn't know where the community was focused, they didn't have any specific areas that they wanted to address themselves and just didn't know where to begin. There were also a number of people that would like to help out with core development, but not as the primary creator of a patch/feature. These people want to write a test, write some documentation or review a patch to move an issue on from its current state. I am one of these people.

# Do a round of cleanup in system.css, and ensure code is in the appropriate CSS file.
# Remove code, and possibly entire files, that clearly do not belong, e.g. border, color, font-family, margins, paddings, etc.
# Keep CSS that provides helpful visual cues, and accessibility compliance, such as system messages, progress bars, etc.
# Completely separate admin styles into separate files, i.e. use block.admin.css instead of block.css, when the purpose of the file is purely administrative.

took the time to go through a lot of issues on drupal.org, to take a large step back, and to recall the entire awesomeness we added to Drupal 7.

changes should increase the ease and incentive of contributing major improvements to core as part of the regular development work.

• More core committers, general or for subsystems
• Shorter development cycle
• Allow new/non-breaking API changes within major release lifecycle

I endorse that last most strongly.