Hi,
I'm going to be at both sprints so I have a few thoughts overall of things I'd either like to look at. First sprint
- Timezone handling (esp Civimail where a cron doesn't understand when the mail should be sent if different timezones are in play but also really relevant to events. We have had this in production in a limited way for over a year as a patch) - issues.civicrm.org/jira/browse/CRM-9683
- Put this ACL issue to bed finally issues.civicrm.org/jira/browse/CRM-10667
- not huge priority for me but Dgg & I talked about looking at the hard-coded limits on batch-update by profile issues.civicrm.org/jira/browse/CRM-10806
Second Sprint - since the A-team will all be at the second sprint it would be good to work through some of the larger issues we have been working through
- Settings API issues.civicrm.org/jira/browse/CRM-10040
- Pseudoconstants / checking in API issues.civicrm.org/jira/browse/CRM-10072
- Price set related changes impact on api
- I would love to look at adding a GUI based Event import - but make it use the api properly - (the existing ones are using aspects of the api but not really using it (not least because the api needs functionality added - see #2). Using the API properly would help to ensure the GUI development & api development are more in sync)
There are a couple of other issues of high interest to me - whether they are manageable within the sprints is doubtful
- look into adding a UI for adding tables into CiviReports rather then hard coding them all - more like views - this is largely in response to things like https://github.com/eileenmcnaughton/nz.co.fuzion.extendedreport/pull/2 & is more easily doable in the context of the extension to reports than the main report framework because in the extension there relatively obvious path to exposing the available joins to the GUI
- Also, on the long list is issues.civicrm.org/jira/browse/CRM-10018 restructure activity contacts to make it easier to query without bad joins / poor performance / temporary tables / avoidable code complexity