Given the huge amount of work, the liability and legislative issues and problems with transferring funds across international borders, I'm not persuaded;
Hence why I said "part"; this wasn't meant to be a persuasive argument, it was just a comment on this particular issue. The other topics you mention should probably be discussed in a different thread.
having dozens of paid fundraising teams is not cost-effective by any stretch of the imagination. The process was stopped because it was costing more money to raise funds that way, and as a movement it's very, very difficult to justify the international level of fundraising in a way that results in much higher costs.
{{citation needed}} please. That's an interesting perspective that I haven't heard before, and I haven't seen any supporting evidence for that argument. But again, that is a different discussion.
Having said that, the Wikimedia movement calendar is becoming increasingly complex. It is inevitable that there are going to be conflicts between major local initiatives and major international-level initiatives; these don't always involve fundraising, although they're probably the most common group affected. I think we really need to get better at scheduling events and creating a solid movement-wide calendar that identifies major activities, particularly those that rely significantly on site advertising/banners/messaging for their success. The further in advance a potential conflict is identified, the more likely that good and effective solutions to those conflicts can be put into place. It would be really helpful, for example, if the Fundraising calendar was published a year in advance; chapters and other groups would probably find that really useful in planning major local activities.
That was my point: if we worked on a national rather than international basis as a baseline, then this sort of issue simply wouldn't arise.
I this specific case, there's not much time left, and so it is time to look for ways to lessen the impact of the scheduling conflict.
I agree with this.
Thanks, Mike