This is a question for those who've coordinatored projects already. Are there any suprising things the you wish to god someone had told you before you started your project? I'm just looking for little tips and tricks you've learned about organizing things, there's gotta be more to it than just making sure everyone uses the same resolution/frame rate.

godix wrote:This is a question for those who've coordinatored projects already. Are there any suprising things the you wish to god someone had told you before you started your project? I'm just looking for little tips and tricks you've learned about organizing things, there's gotta be more to it than just making sure everyone uses the same resolution/frame rate.

The best thing I did that I clearly saw results from last year with AnimeNext's contest was placing a "Quick Check" list at the VERY TOP of the official entry form. Anything that you as the coordinator absolutely know you're going to want/look for... throw it up top with a little box to check off.

Typically, your general entrant just isn't going to read much beyond the top of the page, so might as well throw that important stuff up there with as little explanation as possible (thought I did include it with the full-blown explanations in the official rules). I didn't have to re-encode a single video for last year's contest because of it, and it was great ^^;;

Well I didn't coordinate a project from the start but things I clearly remember from Animix are people signing up and being quiet for a few months, not responding to your emails. The stressful thing as a coordinator is to hunt for people if they're still alive and editing. Second would be what kind of quality some editors come up with, it can be tricky to basicly retell them the whole guides for getting their track in good quality.

Being a bit strict can be good in this case, throw people out if they don't respond to your emails for weeks. However if there aren't many possible participants this might not be a good solution...

godix wrote:This is a question for those who've coordinatored projects already. Are there any suprising things the you wish to god someone had told you before you started your project? I'm just looking for little tips and tricks you've learned about organizing things, there's gotta be more to it than just making sure everyone uses the same resolution/frame rate.

I've only just started running a project and finding out how how nerve racking it can be. But here is a peice of advice to leaders from a participant:
Being firm and taking responsibility for getting things done is important. But don't be afraid to ask for advice.

and

At the end of the day, the proccess is more important than the final product. For me Intrumentality: Animasia isn't a video. It's the freinds I made along the way, it's mutal respect. That 74 page thread in this forum is Animasia as far as I'm concerned. And I wouldn't trade the experience for anything else I have done, or will do, in the AMV world.

pen-pen2002 wrote:
At the end of the day, the proccess is more important than the final product. For me Intrumentality: Animasia isn't a video. It's the freinds I made along the way, it's mutal respect. That 74 page thread in this forum is Animasia as far as I'm concerned. And I wouldn't trade the experience for anything else I have done, or will do, in the AMV world.

Awww.....that's so cool . Thank you, Pen-Pen.

---

One a more technical note, I've a few bits of advice to give, in no particular order:

- Be prepared to work with people a hell of a lot more skilled than you are. Unless you're AD or Scintilla, or some other such expert, chances are very good that you'll realize at least some of the other people in your project are more talented or more knowledgable than you are - and that there are times when the best artistic role you can play is to stay out of the way and let them work their magic.

- That new edit functionality would have been very useful in the early stages of Instrumentality/Animasia. Back then, we actually did have to try to keep up with every new post in the thread (and it's a very long thread) to know what was going on as the (originally very fuzzy) requirements changed or were clarified. Now that you can do edits, I highly suggest putting up a "quote" box (attribute one to "Guidelines" and another to "Status") somewhere in the opening post where you keep:

the current version of all of the project rules

a list of project members

a 'tracklist" representing the temporal arrangement of everyone's segments, or at least a draft of that arrangement

a status list for what parts are done and what parts need to be done

notes concerning anything that was changed and why the change was made

- DO try to get to know the people on the project, especially if it's a long-term one. You'll find that having some impression of their personal style, interests, and way of interpereting things will go a long way toward being able to smoothly direct the project - and to, as Pen-Pen said, make some friends and enjoy the process.

- Try to set some schedule for when parts of the project will/should be done - but be prepared to alter that schedule as all of those little details called "reality" come into play and slow things down. Your approach to scheduling should also take into consideration what you are producing. In the case of Instrumentality, we weren't trying to have it ready for any specific convention or contest, and are more concerned with giving everyone who wanted to submit something ample time to get it done and with making the final product something polished that adds something beyond the sum of the parts to the whole. Other projects, however, might have a hard deadline to meet - and these should have a more rigid but clearly predefined schedule so everyone will what the cutoffs are for joining and what has to be done by when.

- Try to figure out the technical details of how you're going to compile the project before you actually have all of the footage for compilation. It will save you a lot of headaches if you start digging through man pages (um, I mean "help files" - for the commercial OS peoples) and internet tech forums looking for the best possible way to transcode and combine the project files. If anyone wants to ask me how I've been doing it, I'll be happy to get into a detailed explanation. I will say right now that it's possible to combine MPEG1 and MPEG4 streams without re-encoding them if they are in the same encoding - in other words, you can compress everyone's lossless / extra-high-quality renders (adjusting framerates, aspect ratios, display resolutions, and applying some smart artifact-reducing filtering as you do so), and then combine the footage. This knowledge is, of course, the product of realizing that I couldn't store a losslessly encoded two-hour film and all of the files it is made out of on my hard drive - as I learned the hard way by trying to do so, only to run out of disk space.

- Keep it simple. You'll have a lot of grandiose ideas of what can be done - and chances are that you're right, it can be done. Just not by you, not it the timeframe you have to work within, with the tools you have at your disposal. I think there was one point in the Instrumentality project where I thought I was going to do a 3D render of a beautiful studio with moving strips of film gathered from all of the videos scrolling all around the background like one of those "strange attractor" diagrams in fractal picturebooks, with a different talking animated character in every narrative lip-synched to every word in every narrative. If I wanted to drag the project out for another year so I could try to figure out Maya on my roommate's computer when he's not using it to work on his own 3D animation assignments - this might be a good idea. Since I'd like to actually finish the project, however, I settled upon a 2D "set" scheme that was still attractive, but a hell of a lot easier to make and to make look good.

- There were times when I wasn't all too convinced that everyone actually had anything put together for their segments - but, as it turns out, some of us like to post things in versions, and others pretty much didn't want to show anything until they felt it was ready to be seen. Since some great videos were made both ways, I don't there's anything wrong with trusting your project members to come up with something wonderful, even if you haven't seen it and they haven't really explained what they're doing.

- Don't try to decide everything by referendum. Doing this this way gives the other members more "say" in the project's final form - but takes a long time and often leads to confusion as to what the group consensus really was. I guess I'd suggest that you say "here's what I think we should do", and welcome comments and criticizms. That way, there's at least an original plan and you'll only have to worry about changing it if it really does clash with what one or more other people on the project think should be done. I am, by the way, talking about artistic decisions. Technical decisions (frame rates, encodings, aspect ratios, resolutions...) really should be mandated up front, and then you should help anyone who has trouble meeting one of them to find a way to do so.

- It'll take up more of your time than you probably expect. "Managing" doesn't really take all that long - but you also have to consider the number of posts you'll be reading so you'll know what going on, and the number you'll have to write so everyone else knows what's going on. You'll probably also have to do a fair amount of technical research as technical issues arise, and chances are pretty good that you'll be spending some more time on content creation (as I was with me video segment, and now am with all of the "glue" sections). You really should also expect part of the time you spend on the project to be social - which I consider a good thing, but is something to consider if you are already working on a tight schedule.

- You should establish a convenient way to exchange project files (video previews and such) and information as soon as possible. FTP seems to be a good system for handling files, and keeping all of the project communication in your project thread eliminates any issues you might have with trying to keep track of who knows what, and who needs to know what. You should also try to come up with a backup plan for the file exchange if the main method becomes temporarly or permanently unavailable (FTP mirrors, for instance, which were a big help for two points in the Instrumentality project where I was unable to keep my own FTP server up).

- A web page might be a good idea. Try to make it better than the one I came up with. Also try to keep it in synch with the Forum (I didn't do that, either). Come to think of it, now that you can edit you r first post, the web-page thing isn't all that great an idea unless you're thinking of it as more of a promotional thing.

- Don't "dissapear". If you know you'll be swamped and unable to follow communications for a while, at least say so. This way, you can take a break when you need to without anyone thinking you've abandoned the project.

- If you're doing something that's taking a long time, and that doesn't lend itself to being posted somewhere for the participants to take a look at how it's coming along, you should probably give periodic textual updates of what you're doing so the other members know what's going on and have a chance to give you their suggestions.

- When you think someone's done a great job on something, say so. It seems obvious, but we all sometimes forget and take other people's talents and efforts for granted, so do your best to thank them for what they've been doing and point out a few outstanding points of their work. This also has the benefit of defining quality targets that are much more clearly defined than "it should look good, and be creative". It's a lot better to be able to, for instance, evaluate your final encoding quality as related to "Forbidden Memories" because "Forbidden Memories" is a very well-defined example of "it should look good". It is also sometimes a good idea to ask how someone did something that you think is really great - because you can learn a lot this way, and it might be something that other people can in some way apply realizing their own artistic visions.

may seeds of dreams fall from my hands -
and by yours be pressed into the ground.

I think one of the simplest pieces of advice would be getting on a project in which the coordinator is active and vocal during the whole process. If you get constant updates on what the coordinator is up to, and work directily with him/her, you'll probably get a very good idea of the time, effort and tasks involved.

Good online infrastructure is probably the biggest single technical demand. I would like to try running a project, myself, but I'm not doing it without having a solid connection and an FTP server proper.

***

Useful thread. I think another one of such sort this forum needs is a thread for people to discuss project ideas that they aren't totally sure about. An interest gauge/brainstorming thread, or something

The Birds are using humanity in order to throw something terrifying at this green pig. And then what happens to us all later, that’s simply not important to them…

rose4emily covered most of the basics. Having a 2nd in command is a good idea as well, and makes it much easier to keep an eye on what's going on, who owes parts, etc. It also gives you someone to toss ideas back and forth with when it comes down to crunch time (transitions, etc). And of course, if you're frustrated about the state of the project (people not getting their segments in on time, quality sucking, technical woes, etc), it's nice to have someone who will listen to you rant and rave for a while. Of course, I was naive and ran TCP pretty much solo, but I had a pretty cooperative group who helped out a lot. Still wouldn't have minded an XO, though.

Also, <i>enjoy</i> it. Relish it. Running an MEP shouldn't be a chore or a job, it should be an experience. You're bringing together several talented people and the collective result of their talents will be something that hundreds and thousands of people will enjoy. I still think it's incredible how many people have seen TCP so far and that people still leave opinions about how much they think it rocks. I value my participation in the multi-editor projects I've been in as much (if not more than) I value my own videos, because nobody can deny that they're a step above everything else, and that should be true for everyone, both organizers and participants.

I agree with JCD and MJ (and the others as well, all I've read was exactly what we've encountered with animix), and I want to emphasize on this:
The most difficult part is managing the participants.
It is impossible not to have dropouts (and most people who drop out won't warn you), or people who didn't read the guidelines, .

Therefore I think it is very important to keep contact with everyone (as Otohiko said, be active and Vocal) and make sure as often as possible that everything's going well.

Also, if there are technical requirements or deadlines, I think the coordinator has to be strict (which I was not, actually) or the quality of the final product will suffer.

The technical things behind this is stuff we can learn by ourselves when making AMVs, except the "online infrastructure" mentionned by Otohiko.
Obviously it is also important to give technical guidelines to the participants if you don't want to play too much with AVISynth afterwards...