Remove an obsolete TODO; use stronger wording to tell people they should *ask* us before implementing something (native speakers, feel free to correct my english :-)

svn-id: r18686

1 files changed, 12 insertions, 7 deletions

diff --git a/TODO b/TODO
index fa6f0fb7f3..455a0f569c 100644
--- a/TODO
+++ b/TODO
@@ -7,10 +7,18 @@ useful contribution. Note that this list is never complete, and may be
 partially outdated, so just because you don't see something here doesn't
 mean it is not important.
 
-Before you start work on something, you might want to talk to somebody
-from the team. This will help us to prevent double work, i.e. several
-people working on the same stuff at once without knowing about each
-other.
+Before you start work on something, you should first talk to the team!
+Ideally ask on scummvm-devel, our mailing list. This will help us to
+prevent double work, i.e. several people working on the same stuff at
+once without knowing about each other. Furthermore, sometimes entries
+on our list are actually obsolete (because the feature has been
+implemented, or because for some reason we no longer think it to be
+desirable). Special caution should be taken for TODO entries that say
+"we may want to" or similar things; that usually means that we aren't
+sure whether we really want to implement that feature.
+
+So, to repeat it: Always talk to the team before implementing a change
+on this list, or else risk having your patch rejected :-/.
 
 Finally, always make sure to check out our bug tracker and our feature
 request tracker for things that need work.
@@ -83,9 +91,6 @@ General
   we set when the application should be quit (e.g. when an EVENT_QUIT is
   received). This is useful if multiple levels of event loops have to be ended
 * Fix the Map<> template, make it more robust; maybe use a red-black tree?
-* Instead of the above, consider switching everything over to the STL.
-  Maybe a little bit more overhead, but we get instant access to a full-featured
-  and well-tested code base, with everything we need.
 * Make some generic "EventLoop" API/class which all backends and the GUI
   use. Initially this would just call the backend poll_event() etc. methods.
   But eventually the EventLoop object(s) could be made by the backend.