Voting starts in March for the Drupal Association Board election.
I wrote this up in a blog post, and just remembered I hadn't created an issue for it - I'm actively working on this now:
When the concept of migration groups was introduced, I made them a class, MigrateGroup. All we've done with groups up to now is give them names, so having the class has been overkill. I think now is the time to start leveraging groups as objects in themselves. First off, group names up to now have been treated both as machine names (unique identifiers) and display names (shown in drush output, and now in the UI). We should have distinct machine and display names - and the wizard API (which currently prompts for a group name) should set them automatically. For example, in the WordPress case, the group display name could be derived from the blog title and URL in the source file - e.g., "My WordPress Blog (myblog.wordpress.com)", while the machine name (not displayed in the UI, mainly of use for power users issuing drush commands) would be a scrubbed version of the blog title as it is now - mywordpressblog.
More DX than UX, I also want to start using the MigrateGroup class to store information common to the migrations in the group. Currently, wordpress_migrate stores the input filename in the arguments of all migrations, while migrate_d2d stores connection info. Ideally we should normalize this information by storing it in the group, which implies we introduce a group table. Since apart from the machine name (which would be the primary key) and display name, the group data would vary according to the implementing module, so would be stored as a serialized array. Perhaps we could also store state information (when the last import for the group was run, what was the total running time, etc.).