It seemed wiki is better for recording bp and other users(not dev?)
can have a nice look. If we put all in pad, it may be mess for
different bp?
We have some facts:
1. bp needed to be formatted and have a unified view for viewers
2. heavily changes will be applied during CDS mainly
3. latter(after
Mostly I just want to do small incremental changes to the process,
especially since it's happening so close to the summit.
The only thing that I'll miss with an etherpad-only workflow is the
notification on creations/edits, but I'll survive. I think it's just a
matter of enforcing the use of bluep
On Mon, 16 Feb 2015, Patrick McGarry wrote:
> I think I'm going to take this forward in baby steps. I'm going to collect
> blueprints via the normal pathway and then just manually capture the data in
> ether pads when I populate the schedule. For J I'll just direct people
> directly to ether pads (
On 02/05/2015 02:50 PM, Sage Weil wrote:
I wonder if we should simplify the cds workflow a bit to go straight to an
etherpad outline of the blueprint instead of the wiki blueprint doc. I
find it a bit disorienting to be flipping between the two, and after the
fact find it frustrating that there
+1 I've always found the sometimes-populated-sometimes-not blueprint
docs confusing.
John
On Thu, Feb 5, 2015 at 2:50 PM, Sage Weil wrote:
> I wonder if we should simplify the cds workflow a bit to go straight to an
> etherpad outline of the blueprint instead of the wiki blueprint doc. I
> find
I wonder if we should simplify the cds workflow a bit to go straight to an
etherpad outline of the blueprint instead of the wiki blueprint doc. I
find it a bit disorienting to be flipping between the two, and after the
fact find it frustrating that there isn't a single reference to go back to
