Quote from Pippi436:
Wayne: its probably a nice way to present your project. But if you say your goal is to be programmer friendly, you need in depth docs anyways.
Agreed. The main problem with documentation that must be avoided is that software documentation in general is always out-of-date even if it's "mostly" good. Furthermore, for open source code, often the source code itself like TZ is by far the best, most accurate, and current documentation.
However, we have 3 solutions to provide good documentation beyond making 90% of functionality open source.
First
1. Absolute commitment to intuitive naming and renaming of properties, methods, classes, and variables. Current users often report they find what they need easily using the "autocomplete" features in the IDE.
For example, we use very clear, common names for things like BarCount, FullPointValue, etc.
This form of documentation is only useful for sophisticated traders. Newbie traders will feel lost if they don't already know the basics.
2. The next step in documentation is to put comments on properties, methods, and class in a standard format so that it can have automatic generation of documentation. PLUS, those notes appear in autocompletion in the IDE.
In this case, we only plan to comment those which are non-obvious to experienced traders as explained next.
3. Finally, there are concepts in TickZOOm which are non-obvious from the classes, methods, and properties and need a more "wholistic" explanation. Those get covered on the wiki.
Also, there are some properties and features that don't exist in other systems so they're often new to TZ users--so those some explanation since they're new concepts.
There's several new and very useful concepts and abilities in TZ due to it's design which make automation of strategies drastically easier. Those get explained on the wiki.
Quote from Pippi436:
I know writing docs sucks, is time-consuming, expensive and no one wants to do it, but ...
Most programmers would agree with you because they were never really trained at technical writing.
Personally, I had a lot of training and experience at technical writing and people often comment about the clarity of my technical writing. When you're good at something you tend to enjoy it more.
However, the lack of focus on documentation is directly a result of the input from current users. Once you're a user or trial user of TickZOOM, pippi, your opinion will have a lot more weight.
The current users agree more documentation would be good. But they that feel certain other features are more necessary as a priority.
Quote from Pippi436:
... it would save everyone, tz support included, a lot of trouble and resources. VisualStudio/C# would only be half as useful without MSDN, guessing its the same with tz (maybe to a lesser extent).
Not so. The MSDN is necessary because Windows uses a closed source policy unlike TZ. True, .NET is viewable via decompilers, but you can't easily traverse the code or make changes to it and recompile like in TZ.
Quote from Pippi436:
And i think the class reference would say 100 times more about a project than any feature matrix. Also, prospective clients can evaluate if/what progress is being made.
Sure. It will come, in time. This again, comes back to the focus of energies on caring for current member needs as a priority to new members.
However, if people keep joining and voting for features ahead of documentation then, well, that kind of documentation may never happen. The users will decide.
TZ allows individual users to pay money to raise priority of tickets either individually or share the cost among themselves. So one or more could force more documentation to get done if they care that much.
Quote from Pippi436:
I don't know (yet again) where you are going with this. Last thing i heard from you is that tz is a 'secret weapon' for only a select few chosen ones and therefor this information (changelog, forum, docs, ticketsystem) is confidential.
That is correct except that the decision was made to be more transparent about the how and why of the selection process.
Specifically, it's purpose is to limit the number of new users and only accept them at intervals that are convenient to really focus on getting the new users up to speed.
It will be most inconvenient for everyone if new users can stop the train and board at any time. Also, it will only harm everyone if TZ gets overloaded with more users than support personnel.
Finally, obviously, users that depend on more documentation will not be the ideal people to join at this time. If they want to we'll give them a chance if we have enough openings.
Quote from Pippi436:
OTOH there is your continued marketing effort/ET sponsorship for new clients. I don't know if this is the case, but if tz is that good and you are looking for prospective clients, i think you should be more transparent with these things (cat in the bag n'all).
Pippi, what is OTOH?
If it were as transparent as it was before, some people, Pippi, will watch and read about TickZOOM to get free ideas for their own software, TZ competitors, or institutions.
Often the MOST valuable part of software development is the requirements and design.
Anybody can code.
I've architected systems where I did the requirements, design and then contractors where hired off the street to code it up.
The true, best value in TickZOOM is the very information that you seem to want publicly available.
So, I'm very sorry, but that level of "transparency" won't happen, it appears.
Instead, that's the huge bonus people get for the 2 week trial.
Then they can decide whether to use the information to roll their own or simply join TickZOOM.
Sincerely,
Wayne
