Writing a manual is a LOT of work. I think I've seen at least 10-15 separate requests for a manual in the past week, so here's my proposal--and I want to make this as official as possible. I'm willing to take a lead point on this, but want to be as inclusive as possible, because one thing I really hate is duplicated work. I ALSO really hate when I want to work on a project and someone comes along and trumps me. It leaves me feeling rather cold--that's not the goal here.
I've seen plenty of folks volunteer to help, so let's get this going--the first order of business is organization. I don't want this to be something that takes away from anyone who is currently working on developing new features--but if you are writing code, and want to add explanations of what happens, then we'll gladly take it.
At the moment, I just want ANYONE who is interested in assisting in the documentation/manual writing process to jump in here and say 'aye'. We'll leave it at that for now.
I think once we have a list of interested parties, we'll move forward. I'm guessing that this will go something like this:
Collect Names
Assign Responsibilities (including QC, editing, & look & feel)
Write Portions
Edit Portions
Look for missing bits
Revise
Make available for comments
Revise
2nd round comments
Re-revise
Publish
Everyone involved would get credit for their assistance, plus the knowledge that they helped out in something really useful. Everyone is welcome, but I do ask that anyone who is unable to really commit to it please consider if you will really be helpful.
A final thought--some sort of arbitration process will be necessary in this whole thing, especially regarding the look and feel. As such, while I am trying to head this up, I favor voting as the ultimate decision process--not autocratic decisions. I am volunteering to guide the process, will make suggestions, but ultimately feel that everyone involved should get an equal vote when it comes to time to make a decision. I'll set up a few more guidelines on that when the time comes.
Let's write a manual ! [help wanted]
Moderators: dorpond, trevor, Azhrei
Let's write a manual ! [help wanted]
0+0=1, for very unstable CPUs.
I'm listing the volunteers here:
Orchard.
BigO
toyrobots
danieljdavis
plothos
leviat
ElCucuy
notsonoble?
azhrei?--probably a bit busy with moderating this forum I take (plus RL)
knizia.fan?--probably just occasionally I take it
kat2cute--editing
themeek
morval
brad--i figured as much, but hey, I wanted him to say it!
Orchard.
BigO
toyrobots
danieljdavis
plothos
leviat
ElCucuy
notsonoble?
azhrei?--probably a bit busy with moderating this forum I take (plus RL)
knizia.fan?--probably just occasionally I take it
kat2cute--editing
themeek
morval
brad--i figured as much, but hey, I wanted him to say it!
Last edited by Orchard on Thu Sep 25, 2008 12:46 am, edited 9 times in total.
0+0=1, for very unstable CPUs.
I'm in.
And I think the scope should be MapTool, because that's what I use, and that's what's gotten out of hand.
I've never found myself wishing for more documentation on token tool, not in the same way. InitTool is obsolete as far as I'm concerned, since Init tracking was added to MT. I've never used the other projects.
It's very difficult to understand what's going on in MT from an entry level. Macros have been an evolution over time, and there are definite areas where you have to search the forums and some pretty obscure threads to find the definition of a function. This is BAD.
And I think the scope should be MapTool, because that's what I use, and that's what's gotten out of hand.
I've never found myself wishing for more documentation on token tool, not in the same way. InitTool is obsolete as far as I'm concerned, since Init tracking was added to MT. I've never used the other projects.
It's very difficult to understand what's going on in MT from an entry level. Macros have been an evolution over time, and there are definite areas where you have to search the forums and some pretty obscure threads to find the definition of a function. This is BAD.
I would say, for scope, all of Maptool. Which is why help is needed.BigO wrote:AYE!
And just to clarify, what's the scope of the manual? All of RPTools? All of MapTool? Only MapTool macros?
Oh, when you sign up, please do give some indication as to what you are most comfortable working with. I have a feeling that we are going to end up with a lot of volunteers for macros and less for everything else.
0+0=1, for very unstable CPUs.
I agree, and I'm a living example of that.Orchard wrote:Oh, when you sign up, please do give some indication as to what you are most comfortable working with. I have a feeling that we are going to end up with a lot of volunteers for macros and less for everything else.
Count me in for macro stuff! I'm a lowly player and have never made my own map. I won't be much use in other areas of documentation.
-
danieljdavis
- Kobold
- Posts: 8
- Joined: Sat Dec 08, 2007 5:51 pm
- Location: Birmingham, AL
- Contact:
Sign me up for "everything else." I look forward to reading the macro stuff, and possibly editing it for clarity, but I'm not qualified to write it.Orchard wrote: I have a feeling that we are going to end up with a lot of volunteers for macros and less for everything else.
I'll help with screen elements, making and editing tokens, token properties, saving and editing campaign files, etc. Anything we need, but I can't do it all myself.
We need a Getting Started section for sure. Screen Elements is a must, and we really should explain the Types of Data (tokens, campaigns, properties) pretty early. I remember in the first few weeks I thought my PCs had to save their tokens all the time for some reason! :/
Macros really are the last thing we need to explain, although they really need documentation. People can use this program without macros, but right now it seems like they can't, or shouldn't.
I totally agree. There could be a 'quickstart' that has the bare minimum that you need to get a game rolling.toyrobots wrote:We need a Getting Started section for sure.
As far as the order of the chapters, perhaps, but not in order of writing, simply because there's so much info to cover that it will take the longest to write. Fortunately with a bunch of us on the project, it can all happen concurrently.toyrobots wrote:Macros really are the last thing we need to explain, although they really need documentation. People can use this program without macros, but right now it seems like they can't, or shouldn't.
I agree that hashing all that out is in order, but let's get everyone signed up.
I really need a sense of what talent and ideas are available first. I'm hoping some more folks with serious technical writing experience show up. My writing experience is extensive, but it's pretty far removed from writing user manuals. On the other hand, I like these ideas.
I like the idea of a quickstart guide. Maybe 'how to host a game in 20 minutes'? I also think a step-by-step (with pics) run through building a moderately complex campaign (complete with lighting) might be useful.
But once we have those two things down, the nitty-gritty of covering the entire program becomes quite complex.
So let's get everyone on board that we can--like I said at the outset--I want to be inclusive as possible.
I really need a sense of what talent and ideas are available first. I'm hoping some more folks with serious technical writing experience show up. My writing experience is extensive, but it's pretty far removed from writing user manuals. On the other hand, I like these ideas.
I like the idea of a quickstart guide. Maybe 'how to host a game in 20 minutes'? I also think a step-by-step (with pics) run through building a moderately complex campaign (complete with lighting) might be useful.
But once we have those two things down, the nitty-gritty of covering the entire program becomes quite complex.
So let's get everyone on board that we can--like I said at the outset--I want to be inclusive as possible.
0+0=1, for very unstable CPUs.
I'll give you my address to send it to.toyrobots wrote:I'm drafting an outline right now. I'll check in every few minutes to see what's up here. What should I do with this when I'm done for the time being?
In the nonce, I like your enthusiasm.
I'm hoping to wait a day so, however, to see if we can't get more people to sign up, as I suspect some of the long term users might have a few ideas about what else needs inclusion that I've missed.
0+0=1, for very unstable CPUs.
I strongly urge you guys to consider a wiki rather than a manual. While a manual can be very convenient for offline usage, I'm not sure it would provide the same usefulness of an actual well put-together (and up to date) wiki would.
Being a MapTool noob here, I know that I was constantly wishing there was a solid wiki available for lookup up functions, preferences, and just some general information.
I realize that RPTools itself is a Doku wiki, but I don't think doku is quite as userfriendly in terms of searching and updating as MediaWiki. This would also encourage other members to help out, provide a decent revision control system, allow it to always be "up to date", and of course allow linking to particular topics from within the forums.
I would even be willing to host the wiki for free if this is what the community would like.
Being a MapTool noob here, I know that I was constantly wishing there was a solid wiki available for lookup up functions, preferences, and just some general information.
I realize that RPTools itself is a Doku wiki, but I don't think doku is quite as userfriendly in terms of searching and updating as MediaWiki. This would also encourage other members to help out, provide a decent revision control system, allow it to always be "up to date", and of course allow linking to particular topics from within the forums.
I would even be willing to host the wiki for free if this is what the community would like.
I'd seriously consider that. Frankly I'd like to see both efforts. A wiki is very useful in several regards, and a manual is also useful. These are the ideas that I want to get in consideration before we finalize plans.leviat wrote:I strongly urge you guys to consider a wiki rather than a manual. While a manual can be very convenient for offline usage, I'm not sure it would provide the same usefulness of an actual well put-together (and up to date) wiki would.
Being a MapTool noob here, I know that I was constantly wishing there was a solid wiki available for lookup up functions, preferences, and just some general information.
I realize that RPTools itself is a Doku wiki, but I don't think doku is quite as userfriendly in terms of searching and updating as MediaWiki. This would also encourage other members to help out, provide a decent revision control system, allow it to always be "up to date", and of course allow linking to particular topics from within the forums.
I would even be willing to host the wiki for free if this is what the community would like.
With that in mind, I'm putting you down as being willing to help, and we'll talk.
0+0=1, for very unstable CPUs.
For the purpose of fostering discussion in the mean time:
The best way to start is with campaign files, as in "What is a campaign file?" since a default one loads as soon as you boot up.
From there, we move on to "What is a Token?"
Then how to make a token. How to move a token. Then we go an explain the 24 (level 1) options in the Right Click token menu, and the 60+ screen elements in the "Edit Token" window.
Then we have a section on Campaign Properties.
A section on map editing.
A section on connectivity.
THEN an advanced section including macros.
The best way to start is with campaign files, as in "What is a campaign file?" since a default one loads as soon as you boot up.
From there, we move on to "What is a Token?"
Then how to make a token. How to move a token. Then we go an explain the 24 (level 1) options in the Right Click token menu, and the 60+ screen elements in the "Edit Token" window.
Then we have a section on Campaign Properties.
A section on map editing.
A section on connectivity.
THEN an advanced section including macros.