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