Correct me if I'm wrong (and I probably missed something), but why do
you and some others in this thread want users to actually edit a
feature?
That's going to wreck havoc with steps that won't match anymore,
breaking features, and therefore making the client angry.
WDYT?
bartz
> My thinking now is that I would perhaps have the customers working on
> a different branch of the code, which was still built in CI but
failed > with a 'softer' noise, to indicate that there was new work to
do. We'd > expect the build for this branch would be 'broken' most of
the time.
I was thinking the same thing with my original comment about letting
people edit the features. I didn't think it fully through though. In our
distributed environment we typically have people discussing stories /
specs what have you over vnc or over the phone or over email and they
change until they are 'accepted'. I was thinking that allowing this type
of interaction in this tool before the specs are actually 'accepted'. eg
keep them pending until 'accepted'/greenlit.
Having developers pull them in would be another way as well. Perhaps
'accepting' could be done with pull requests. The accepting / pulling
paradigm would depend on how you wanted to handle half done specs and
not yet implemented features.
Please bear with my terminology as I'm 1/2 way in the test::unit world.
-Mike
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
