Work Flow Management

[Mac_Fife]

Following up on this, I'm wondering if it's worth while trying to outline the "Use Cases" here - listing what tasks a user may want to perform:
"I want to submit a bug report"
"I want to see what bugs I could work on"
"I want to commit my bug fix"
"I want to report on testing a bug fix"
etc.

I think it'd be easy to get too "fine-grained" on something like this, and end up missing the point of what the real "task" is: Perhaps the second one I listed is really "I want to check the status of bug reports" and is equivalent to "I want see which bugs are not being worked on", or "I want see what bugs have been resolved".

[Mac_Fife]

I owe this topic some input... I've managed to start on doing some diagrams of my own, which I hope to be able to share in a few days.

[DarK]

I have to say the same as well - just reminding myself of whats is what.

Looking forward to seeing your diagrams

EDIT: Mac, sorry my R/L has just taken another unexpected turn

Basically an old employer, no longer have the expertise in-house to manage a part of a project that they were dealing with, and so are chasing me with some sort of view of re-employment/short term contract.

Depending how this is all going to pan out I am possibly going to be busy for the next month plus, as my personal time will be taking the hit with the extra work.

I hope to at least spend time passing an eye over your diagrams and lending a hand with a few comments however, just to let you know that I may not be instantly on hand after you post them!

[Christian Walther]

I originally planned to ignore this thread and just see how things unfold (and will likely continue to do so), but since you’re asking for feedback, I’ll be honest: My first reaction on your diagrams was “Good grief, do I need to understand all that to be able to contribute here?” I haven’t put in the effort to understand what you’re proposing, but on the surface it looks extremely complicated. I hope this is just internals on the way to a simple result for everyone, just something that those who are interested in management may enjoy fiddling with, but those who don’t want to don’t need to follow.

[rarified]

Diagrams with this detail (or even more) wouldn't be what I present to casual users, but the benefit of them appearing here is to avoid as many ambiguities as we can anticipate, show all the required resources and invested actors, so we're all on the same page. I'd expect we'll have some simpler diagrams and prose to handle one situation at a time, that get posted on the wiki.

[JWPlatt]

It's pretty scarey to me too, but I appreciate the work. I won't pretend to understand it all. I'm happy to see the participation. And I'll be content to watch the progress and see how it turns out in terms of mouse clicks.

[DarK]

You are in the right area; you don’t need to understand the whole diagram and you are correct in that it’s a means to an end.

Process diagrams, in this case DFD’s show, to the best of the writers knowledge, what needs to happen to achieve something.

For example, you can say “I boil a kettle to make tea”, but been more verbose gives more information into how you make tea such as “I use a tap, to pour water, into a kettle, that then heats the water to boiling point, which I then pour into a cup, then add the tea, and milk, to make tea”.
This way there can be less confusion about how I make tea

I am potentially using the diagrams as a way to map development processes based on people’s discussions and the actions that have happened. This way we can potentially add the missing pieces of the puzzle that are needed to get openUru moving.

Colour code as before:

Black : Already implemented
Red : Proposed
Orange : Question Marked process – unsure if it actually happens
Green : Automation



The dashed box represents a branch development.

Ideally, as a developer you will only needed to understand this section of the diagram, and how the lines leaving and entering the box, affect you.

From diagram we can tell people who are using repo what needs to happen from their point of view to get the code into an openUru repo.
In this case, developers will make a pull request from their repo, which will generate an issue ticket for attention in JIRA. This in turn gives the developer and repo controllers a point of contact in JIRA for any pull discussion and the status of the pull.

That’s it for the developer, but this information can now be distilled into a document on how to commit work if needed.

From the repo controller point of view, the diagram shows that they pick up a pull issue from JIRA, confirm the pull against any known pull rules (does not trash the repo, is incremental etc) , then perform the pull and update the JIRA issue.

Again the verbose nature of this has shown us that we could need someone to manage the repo, a set of Pull rules, and a standard way to document these requests in JIRA, prior to any implementation.

These points can be discussed if required, or they can be ignored for now and work done elsewhere if a higher priority issue is at the forefront of people’s minds.

Does there need to be discussion around the “fly by patchers” as they can push patches into fisheye directly – which means that their code is straight into review, is that acceptable?!

Additionally there are some outstanding issues with where to place code review - before the commit or after. For the issue to apear in fisheye, the commit needs to occur first - otherwise developers will need to manually create the review, which I am certain is not going to be a popular option.

Finally, is patch submittal/acceptence a requirement to been allow to submit from repo with Pull requests? If so the repo contollers decision on a pull request is not required, however a decision needs to be made on procedure of what grants Pull requests.

[rarified]

I just noticed this set of release notes for the next version of JIRA (4.4) which looks to be near release.

Scroll down, there now is a graphical/visual presentation of a project's workflow. It looks like we could leverage that (if we keep it simple) to present the flow to a general audience.

_R

[DarK]

I just noticed this set of release notes for the next version of JIRA (4.4) which looks to be near release.

Scroll down, there now is a graphical/visual presentation of a project's workflow. It looks like we could leverage that (if we keep it simple) to present the flow to a general audience.

_R

It is worth looking into, as over time processes can change (shift happens) - and easy to access documentation tools on how things work are easier to understand than reams of text.

As a final result - I tend to think that "process flow" style diagrams are what is needed to indicate input & output in a none complicated way. This aiding people to ask specific questions when things go wrong, and for others to join in the "process flow" or take over in case of absence.

Single reliance of a single person is not an option, so when change occurs these tools should help get everyone on the right page.