diff --git a/0000-template.md b/0000-template.md
index d1dad5534c6..3581b5e1735 100644
--- a/0000-template.md
+++ b/0000-template.md
@@ -1,29 +1,30 @@
-- Start Date: (fill me in with today's date, YYYY-MM-DD)
+- Start Date: 2015-03-25
 - RFC PR: (leave this empty)
 - Rust Issue: (leave this empty)
 
 # Summary
 
-One para explanation of the feature.
+When calling `println!` it currently causes a panic if `stdout` does not exist. Change this to ignore this specific error and simply void the output.
 
 # Motivation
 
-Why are we doing this? What use cases does it support? What is the expected outcome?
+On linux `stdout` almost always exists, so when people write games and turn off the terminal there is still an `stdout` that they write to. Then when getting the code to run on Windows, when the console is disabled, suddenly `stdout` doesn't exist and `println!` panicks. This behavior difference is frustrating to developers trying to move to Windows.
+
+There is also precedent with C and C++. On both Linux and Windows, if `stdout` is closed or doesn't exist, neither platform will error when printing to the console.
 
 # Detailed design
 
-This is the bulk of the RFC. Explain the design in enough detail for somebody familiar
-with the language to understand, and for somebody familiar with the compiler to implement.
-This should get into specifics and corner-cases, and include examples of how the feature is used.
+Change the internal implementation of `println!` `print!` `panic!` and `assert!` to not `panic!` when `stdout` or `stderr` doesn't exist. When getting `stdout` or `stderr` through the `std::io` methods, those versions should continue to return an error if `stdout` or `stderr` doesn't exist.
 
 # Drawbacks
 
-Why should we *not* do this?
+Hides an error from the user which we may want to expose and may lead to people missing panicks occuring in threads.
 
 # Alternatives
 
-What other designs have been considered? What is the impact of not doing this?
+* Make `println!` `print!` `panic!` `assert!` return errors that the user has to handle.
+* Continue with the status quo and panic if `stdout` or `stderr` doesn't exist.
 
 # Unresolved questions
 
-What parts of the design are still TBD?
+* Should `std::io::stdout` return `Err` or `None` when there is no `stdout` instead of unconditionally returning `Stdout`?