tortoisebzr-developers team mailing list archive

["C. Mundi" <cmundi@xxxxxxxxx>]

Mark,

Good points, all.  You did a better job of saying what I was trying to say.
Users should choose their workflow (possibly with some nudging from their
peers).  I really like the words you're using to describe the workflow
scenarios -- accurate without imputing subjective value judgments.

You've just hit on one of the main reasons I have not written my own front
end -- I am not sure how to turn these abstract ideas into concrete menu
options.  I have some pieces, but nothing that gels into a cohesive whole.
You caught me.  :)

My strongest approach so far is allowing the user to create a "workflow
profile" which is essentially a per-user and/or per-repo bitmask of config
options controlling which options are available for each "common task."  The
notion of "common task" maps pretty well to your concept of "hybrid"
dialogs.  The user could edit this profile if they are comfortable, or they
could simply copy the profile adopted by a project team.  The ability to
share profiles would help out a lot of teams and reduce the need for some of
the heated discussions I've had to break up (er... I mean "facilitate.")
over the years.  [As an aside, creative teams have enough "issues" to
overcome.  Add a profit motive and -- wow -- stand back!]

The question then becomes, how to identify some generally useful workflow
profiles to get people started.  I'm a theorist turned empiricist, so my
approach would be to put a profile in place and then observe how it gets
"tuned" in some real-life projects.  That's a cop-out, to be sure, but
calling it empirical makes it sound better...  Like I said, you caught me!

cm


On Tue, Aug 26, 2008 at 8:08 PM, Mark Hammond <mhammond@xxxxxxxxxxxxxxxx>wrote:

> Hi Carlos,
>  Thanks for the feedback,
>
> > The problem of pushing changes or calling for a merge is
> > a lot harder.  Here, maybe TBZR  needs a config switch.
>
> > Mode 1 is for people who are trusted to push their own changes.
>
> This would probably need to be phrased as "trust themselves to push
> changes"
> (ie, it is something they personally opt-in or out of), but it is possible
> something like this is workable.  In effect, its "just" another
> user-preference that controls the UI.
>
> > Even here, there are multiple workflows, but just being clear that it's a
> > push simplifies a lot.  Mode 2 is for people who have to ask
> permission/help
> > to merge their changes back into a mainline.  Again, there are choices,
> but
> > fewer than there would be if the modes were all combined.  Modes 1 and 2
> are
> > so different socially, that separate "modes" seem prudent.
>
> > The project leader would decide who's a Mode 1 user and who's Mode 2.
>
> This would be moving towards storing that information in the branch itself,
> which isn't going to happen in the short term - but I think that is fine -
> people would be happy to enable an option that says (say) "I'm more
> comfortable with a centralized VCS model" if it meant the tool better
> supported that preference.
>
> My problem is that this is still too abstract for me to build a mental
> picture of.  Could you possibly develop this a little more into some
> specific ideas about how the UI would adapt to this preference/model?
>
> Thanks!
>
> Mark
>
>