change a couple I've to we've

diff --git a/FAQs/apogee-above-100k.mdwn b/FAQs/apogee-above-100k.mdwn
index b4fba3b44a2c7edd39252d9ec8f296946ae17308..77b77c481c7cdf8ccf28e0b00d114adffb63a97f 100644 (file)
--- a/FAQs/apogee-above-100k.mdwn
+++ b/FAQs/apogee-above-100k.mdwn
@@ -51,18 +51,18 @@ close. After that, as you're flying purely on accelerometer data,
 there's no way to re-correct the state, so the apogee estimates can be
 off by quite a bit.
 
-In the worst cases that I've seen, the baro sensor data was wildly
+In the worst cases that we've seen, the baro sensor data was wildly
 incorrect above mach due to poor static port design, leaving the state
 estimate of speed across the 30km boundary way off and causing the
 apogee detection to happen far from the correct time.
 
 The good news is that correctly determining apogee is not really all
 that important at those altitudes; there's so little density that a
-drogue will have almost no drag anyways. The data I've seen shows a very
+drogue will have almost no drag anyways. The data we've seen shows a very
 parabolic path down to about 50k'-60k', even with a recovery system
 deployed...
 
-So, what I've been recommending is to set up two apogee plans:
+So, what we've been recommending is to set up two apogee plans:
 
  1. Use the built-in apogee detection, but add a significant delay (as
     much as 30 seconds). This will probably fire near enough to apogee