Re: [Discuss] OpenProject Work Packages Workflow
On 02/12/2016 04:44 PM, Bryan Richter wrote: > On Fri, Feb 12, 2016 at 02:12:59PM -0800, Aaron Wolf wrote: >> On 02/12/2016 02:00 PM, Bryan Richter wrote: >>> >>> Hmm, yeah, maybe co-op/money/website are a lot more interdependent >>> than I was thinking. That makes me wonder — what is the plan for >>> co-op and money? If they are going to impact site development, and >>> be impacted by it, we need a holistic roadmap. I looked around at >>> the Next and Strategy wiki pages and didn't find any mention of a >>> plan. I'm pretty sure there *is* a plan (part of which is drafting >>> bylaws..?). >>> >> >> We need the Bylaws first and foremost, and there's work I need to do >> (partly since Jon, who had done some, hasn't been active lately). > > I think it would be good to list these tasks, whatever they may be, in > OpenProject. > > Regarding the tech roadmap, I have some more questions about the > relationships between co-op requirements and website requirements. > These questions may be rather pedantic, but my hope is to have a > ridiculously clear set of priorities. > >>> Will there be requirements put on the website to achieve any of that >>> vision (non-profit, cooperative, both)? >> >> The website in terms of the projects we support will need to follow the >> legally stated mission. > > So: does the website need to follow the mission before incorporation, > or can it follow afterwards as a work-in-progress? If the former, does > that mean we must be funding other projects before we can incorporate? > (I highly doubt it, but like I said, I want the relationships to be > stunningly clear.) > >> Otherwise, we will need to have infrastructure one way or the other >> for managing the board meetings and membership contracts etc. i.e. >> the basic operations of running a co-op. >> >> ... >> On the tech infrastructure side, we need to have the systems that >> recognize co-op members in terms of board elections and other voting. > > Again: is this infrastructure a hard requirement for our website > before incorporation, or is it something we can fulfill by other > means first? > > I am trying to determine what, exactly, the MVP is. If we can be a > co-op without these features in our website, then it would not be > 'minimal' to have them. > > If we can AVOID having these features until later, that would give a > lot more flexibility to the tech roadmap, and allow us to hit the > milestone of funding ourselves (!!) a lot sooner. > > In short: we *need* to have the co-op governance working ASAP. That means that there are the required roles, the bylaws are set, and we are in fact having meetings and elections. We are not legally required to have these things just to take in money (we're already getting donations), but they really should be set by the time we are saying in any real sense that we are "open for business", and ideally *sooner*. None of that says anything about how we do these things (like whether the manner in which we hold meetings and elections is connected to the core website or not), as long as it follows the bylaws (which must follow legal requirements). A top priority is indeed to finish making decisions about bylaws that our lawyer wants us to make and then get that final stuff back to her. I'm about to be a guest on a podcast again, but tomorrow I should be able to get this stuff onto the OpenProject wiki or something. Some of it is already on the main wiki. We just need a way to all discuss and come to decisions so we finally have clarified stuff to hand off to the lawyer. She wants us to have clear decisions like "what precisely defines a project class member?" and similar things that were inadequately precise. ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Discuss] OpenProject Work Packages Workflow
On Fri, Feb 12, 2016 at 02:12:59PM -0800, Aaron Wolf wrote: > On 02/12/2016 02:00 PM, Bryan Richter wrote: > > > > Hmm, yeah, maybe co-op/money/website are a lot more interdependent > > than I was thinking. That makes me wonder — what is the plan for > > co-op and money? If they are going to impact site development, and > > be impacted by it, we need a holistic roadmap. I looked around at > > the Next and Strategy wiki pages and didn't find any mention of a > > plan. I'm pretty sure there *is* a plan (part of which is drafting > > bylaws..?). > > > > We need the Bylaws first and foremost, and there's work I need to do > (partly since Jon, who had done some, hasn't been active lately). I think it would be good to list these tasks, whatever they may be, in OpenProject. Regarding the tech roadmap, I have some more questions about the relationships between co-op requirements and website requirements. These questions may be rather pedantic, but my hope is to have a ridiculously clear set of priorities. > > Will there be requirements put on the website to achieve any of that > > vision (non-profit, cooperative, both)? > > The website in terms of the projects we support will need to follow the > legally stated mission. So: does the website need to follow the mission before incorporation, or can it follow afterwards as a work-in-progress? If the former, does that mean we must be funding other projects before we can incorporate? (I highly doubt it, but like I said, I want the relationships to be stunningly clear.) > Otherwise, we will need to have infrastructure one way or the other > for managing the board meetings and membership contracts etc. i.e. > the basic operations of running a co-op. > > ... > On the tech infrastructure side, we need to have the systems that > recognize co-op members in terms of board elections and other voting. Again: is this infrastructure a hard requirement for our website before incorporation, or is it something we can fulfill by other means first? I am trying to determine what, exactly, the MVP is. If we can be a co-op without these features in our website, then it would not be 'minimal' to have them. If we can AVOID having these features until later, that would give a lot more flexibility to the tech roadmap, and allow us to hit the milestone of funding ourselves (!!) a lot sooner. signature.asc Description: Digital signature ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Discuss] OpenProject Work Packages Workflow
On 02/12/2016 02:00 PM, Bryan Richter wrote:
> On Fri, Feb 12, 2016 at 03:03:38AM -0500, Stephen Michel wrote:
>> On Thu, Feb 11, 2016 at 5:44 PM, Bryan Richter
>> wrote:
>>> On Thu, Feb 11, 2016 at 04:25:08PM -0500, Stephen Michel wrote:
Pre-Alpha (name?): complete site except funding mechanism, where
hitting the 'pledge' button signs you up for the 'announce' email
list.
- Primary required work: UX & implementation
>>>
>>> There's so much website that we already have — this step feels like
>>> it could be elided. Can you provide justification for it?
>>
>> First - I agree, there is relatively little work to be done. It can
>> probably be completed in 1-2 weeks.
>> Second - A primary function of this milestone is for us to get used
>> to Openproject. I think it would be valuable to go through the
>> process of {Create personas -> create epics (& user stories) ->
>> implement an epic}, even if that epic is mostly implemented already,
>> so we're used to that process when we move on to the next milestone.
>> Third - I would include updating our introductory materials as part
>> of this step. Also, reducing or eliminating "this page under
>> construction" and "this page migrated from the old site so it may
>> not look right" headers.
>
> These are good points, and I would not be opposed to this plan.
>
>>> There's one thing not addressed by any of the above: co-op and
>>> legal structure!
>>>
>>> I think that the co-op project is somewhat independent of the
>>> website project, but I do not know to what degree that is true.
>>
>> I think they are bundled with the above. For example, we need our
>> coop structure in place in order to enter the alpha, because so far
>> we've got, "If you're a patron of the snowdrift.coop project, you're
>> a co-op member."
>
> Hmm, yeah, maybe co-op/money/website are a lot more interdependent
> than I was thinking. That makes me wonder — what is the plan for co-op
> and money? If they are going to impact site development, and be
> impacted by it, we need a holistic roadmap. I looked around at the
> Next and Strategy wiki pages and didn't find any mention of a plan.
> I'm pretty sure there *is* a plan (part of which is drafting
> bylaws..?).
>
We need the Bylaws first and foremost, and there's work I need to do
(partly since Jon, who had done some, hasn't been active lately).
It's not that patrons of the snowdrift.coop project are *automatically*
co-op members. It's that patronage of the Snowdrift.coop is the core
requirement for co-op membership. So, we'll *allow* people to be patrons
without being co-op members, even though I don't know that anyone would
want that.
Co-op stuff is at https://snowdrift.coop/p/snowdrift/w/en/co-op
> I know one of the visions is to be a non-profit cooperative. How does
> that break down?
>
> Do we have to be a non-profit before we become a co-op, or vice versa,
> or ?
>
Co-op non-profit is state-law stuff, totally connected to the bylaws and
incorporation overall. This is a single thing. Please remember that
non-profit is a state designation and not an IRS designation.
> Will there be requirements put on the website to achieve any of that
> vision (non-profit, cooperative, both)?
>
The website in terms of the projects we support will need to follow the
legally stated mission. Otherwise, we will need to have infrastructure
one way or the other for managing the board meetings and membership
contracts etc. i.e. the basic operations of running a co-op. It's
certainly preferable to integrate things as much as possible.
> Will the OSI's incubation have any role to play on the website's design
> and features?
>
No, the OSI doesn't have a role to play aside from support and advice.
Sorry for my not being totally on top of these things, it is
high-priority stuff.
On the tech infrastructure side, we need to have the systems that
recognize co-op members in terms of board elections and other voting.
Perhaps that will mean something like having a way to use keys or
encryption of some sort to have members identified as members and get a
receipt of their voting but keep the votes anonymized, etc. the whole
issue of online democracy (we have contacts to reach out to about ideas
for this stuff). If necessary, we will have to start early operations
with non-anonymized voting (still anonymous results, but just not have
the ability to *ensure* absolute anonymity, i.e. an audit could reveal
identities, which is not ideal, but we may have to have some compromises).
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Discuss] OpenProject Work Packages Workflow
On Fri, Feb 12, 2016 at 03:03:38AM -0500, Stephen Michel wrote:
> On Thu, Feb 11, 2016 at 5:44 PM, Bryan Richter
> wrote:
> >On Thu, Feb 11, 2016 at 04:25:08PM -0500, Stephen Michel wrote:
> >>
> >> Pre-Alpha (name?): complete site except funding mechanism, where
> >> hitting the 'pledge' button signs you up for the 'announce' email
> >> list.
> >> - Primary required work: UX & implementation
> >
> >There's so much website that we already have — this step feels like
> >it could be elided. Can you provide justification for it?
>
> First - I agree, there is relatively little work to be done. It can
> probably be completed in 1-2 weeks.
> Second - A primary function of this milestone is for us to get used
> to Openproject. I think it would be valuable to go through the
> process of {Create personas -> create epics (& user stories) ->
> implement an epic}, even if that epic is mostly implemented already,
> so we're used to that process when we move on to the next milestone.
> Third - I would include updating our introductory materials as part
> of this step. Also, reducing or eliminating "this page under
> construction" and "this page migrated from the old site so it may
> not look right" headers.
These are good points, and I would not be opposed to this plan.
> >There's one thing not addressed by any of the above: co-op and
> >legal structure!
> >
> >I think that the co-op project is somewhat independent of the
> >website project, but I do not know to what degree that is true.
>
> I think they are bundled with the above. For example, we need our
> coop structure in place in order to enter the alpha, because so far
> we've got, "If you're a patron of the snowdrift.coop project, you're
> a co-op member."
Hmm, yeah, maybe co-op/money/website are a lot more interdependent
than I was thinking. That makes me wonder — what is the plan for co-op
and money? If they are going to impact site development, and be
impacted by it, we need a holistic roadmap. I looked around at the
Next and Strategy wiki pages and didn't find any mention of a plan.
I'm pretty sure there *is* a plan (part of which is drafting
bylaws..?).
I know one of the visions is to be a non-profit cooperative. How does
that break down?
Do we have to be a non-profit before we become a co-op, or vice versa,
or ?
Will there be requirements put on the website to achieve any of that
vision (non-profit, cooperative, both)?
Will the OSI's incubation have any role to play on the website's design
and features?
signature.asc
Description: Digital signature
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Discuss] OpenProject Work Packages Workflow
On Thu, Feb 11, 2016 at 5:44 PM, Bryan Richter
wrote:
On Thu, Feb 11, 2016 at 04:25:08PM -0500, Stephen Michel wrote:
Pre-Alpha (name?): complete site except funding mechanism, where
hitting the 'pledge' button signs you up for the 'announce' email
list.
- Primary required work: UX & implementation
There's so much website that we already have — this step feels like
it
could be elided. Can you provide justification for it?
First - I agree, there is relatively little work to be done. It can
probably be completedaa in 1-2 weeks.
Second - A primary function of this milestone is for us to get used to
Openproject. I think it would be valuable to go through the process of
{Create personas -> create epics (& user stories) -> implement an
epic}, even if that epic is mostly implemented already, so we're used
to that process when we move on to the next milestone.
Third - I would include updating our introductory materials as part of
this step. Also, reducing or eliminating "this page under construction"
and "this page migrated from the old site so it may not look right"
headers.
Alpha: Self funding: Real Money, only one project --
snowdrift.coop, mostly-complete mechanism (doesn't need to account
for multiple projects),
- Primary required work: mechanism, legal, ongoing UX
I love this idea! I think it accurately reflects the priority of
figuring out real money asap.
Closed Beta: all of the above plus complete funding mechanism,
invite exclusively popular FLOSS
- Primary work required: mechanism, legal, outreach, ongoing UX
Indeed, this would be the next logical step.
I still feel that "milestone" is the right word for these thresholds.
Seems reasonable.
There's one thing not addressed by any of the above: co-op and legal
structure!
I think that the co-op project is somewhat independent of the website
project, but I do not know to what degree that is true.
I think they are bundled with the above. For example, we need our coop
structure in place in order to enter the alpha, because so far we've
got, "If you're a patron of the snowdrift.coop project, you're a co-op
member." We also need to know some, but not all, of how we will process
transactions. When we go into open beta / early access, we need to know
our legal status (eg, if we're a 501c3, that might restrict what
projects we can take on).
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Discuss] OpenProject Work Packages Workflow
On 2016-02-11 15:25, Stephen Michel wrote: On Thu, Feb 11, 2016 at 2:49 PM, Bryan Richter wrote: On Wed, Feb 10, 2016 at 03:15:38PM -0800, Stephen Yeung wrote: Regarding Milestones they're generally meant for big events (i.e. launches or when you complete a suite of inter-related features) wherein you take stock and review work and see if changes are needed. Right now our two "milestones" are: Alpha: complete website with funding mechanism (but no real money) Beta: Real money!! After that there's a lot of directions we can go, i.e., we'll need to take stock and review. Does anyone have feeback or questions on these two milestones? Feedback, yes. I'm not sure if we should call these milestones, but I think there are several important big events: Pre-Alpha (name?): complete site except funding mechanism, where hitting the 'pledge' button signs you up for the 'announce' email list. - Primary required work: UX & implementation Yes. This is a good approach. It's what my team has done with rackrental.net. Though we just have a free tier that the invited users are in. So site and app are functional but no real money yet. Alpha: Self funding: Real Money, only one project -- snowdrift.coop, mostly-complete mechanism (doesn't need to account for multiple projects), - Primary required work: mechanism, legal, ongoing UX Yes. People have to see that money can move through the system, some people have contributed, features work etc. Closed Beta: all of the above plus complete funding mechanism, invite exclusively popular FLOSS - Primary work required: mechanism, legal, outreach, ongoing UX Yep. I like the term early access, advanced placement etc. Beta is too overloaded. Open Beta: self-explanatory - Primary required work: outreach, ongoing UX Stable At each stage we should re-evaluate our priorities, so the farther down you go in that list, the more tentative. !DSPAM:56bcfc36244981056110400! Yep. Plans of mice and men etc... ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Discuss] OpenProject Work Packages Workflow
On Thu, Feb 11, 2016 at 04:25:08PM -0500, Stephen Michel wrote: > > On Thu, Feb 11, 2016 at 2:49 PM, Bryan Richter > wrote: > >On Wed, Feb 10, 2016 at 03:15:38PM -0800, Stephen Yeung wrote: > >> Regarding Milestones they're generally meant for big events (i.e. > >> launches or when you complete a suite of inter-related features) > >> wherein you take stock and review work and see if changes are > >> needed. > > > >Right now our two "milestones" are: > > > >Alpha: complete website with funding mechanism (but no real money) > > > >Beta: Real money!! > > > > I'm not sure if we should call these milestones, but I think there > are several important big events: > > Pre-Alpha (name?): complete site except funding mechanism, where > hitting the 'pledge' button signs you up for the 'announce' email > list. > - Primary required work: UX & implementation There's so much website that we already have — this step feels like it could be elided. Can you provide justification for it? > Alpha: Self funding: Real Money, only one project -- > snowdrift.coop, mostly-complete mechanism (doesn't need to account > for multiple projects), > - Primary required work: mechanism, legal, ongoing UX I love this idea! I think it accurately reflects the priority of figuring out real money asap. > Closed Beta: all of the above plus complete funding mechanism, > invite exclusively popular FLOSS > - Primary work required: mechanism, legal, outreach, ongoing UX Indeed, this would be the next logical step. I still feel that "milestone" is the right word for these thresholds. There's one thing not addressed by any of the above: co-op and legal structure! I think that the co-op project is somewhat independent of the website project, but I do not know to what degree that is true. signature.asc Description: Digital signature ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Discuss] OpenProject Work Packages Workflow
On Thu, Feb 11, 2016 at 2:49 PM, Bryan Richter wrote: On Wed, Feb 10, 2016 at 03:15:38PM -0800, Stephen Yeung wrote: Regarding Milestones they're generally meant for big events (i.e. launches or when you complete a suite of inter-related features) wherein you take stock and review work and see if changes are needed. Right now our two "milestones" are: Alpha: complete website with funding mechanism (but no real money) Beta: Real money!! After that there's a lot of directions we can go, i.e., we'll need to take stock and review. Does anyone have feeback or questions on these two milestones? Feedback, yes. I'm not sure if we should call these milestones, but I think there are several important big events: Pre-Alpha (name?): complete site except funding mechanism, where hitting the 'pledge' button signs you up for the 'announce' email list. - Primary required work: UX & implementation Alpha: Self funding: Real Money, only one project -- snowdrift.coop, mostly-complete mechanism (doesn't need to account for multiple projects), - Primary required work: mechanism, legal, ongoing UX Closed Beta: all of the above plus complete funding mechanism, invite exclusively popular FLOSS - Primary work required: mechanism, legal, outreach, ongoing UX Open Beta: self-explanatory - Primary required work: outreach, ongoing UX Stable At each stage we should re-evaluate our priorities, so the farther down you go in that list, the more tentative. ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Discuss] OpenProject Work Packages Workflow
On Wed, Feb 10, 2016 at 03:15:38PM -0800, Stephen Yeung wrote: > Regarding Milestones they're generally meant for big events (i.e. > launches or when you complete a suite of inter-related features) > wherein you take stock and review work and see if changes are > needed. Right now our two "milestones" are: Alpha: complete website with funding mechanism (but no real money) Beta: Real money!! After that there's a lot of directions we can go, i.e., we'll need to take stock and review. Does anyone have feeback or questions on these two milestones? > As for Epics, they are user stories but more general and vague, that > can cover a lot of functionality. Think of it like an umbrella user > story that has user stories beneath it. For example, a checkout > process might be an epic, while shopping cart, address form, payment > processor, and confirmation e-mail would be user stories under that > epic. Epics are used to get a general idea of the scope/priority of > the request without breaking everything down.- As for the why it > should be explained as part of the User Story. The general form of > a user story is, As a (actor/state), I want to (function) so that I > can/because I want to (why). Thanks, this makes sense! It is my understanding that people who write user stories may not always know up front if the story is "epic" or not. The details may be unclear to them, or they may not be familiar with the technical requirements, etc. This sort of makes me think that all stories should be "epic" by default, until they have been groomed. signature.asc Description: Digital signature ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Discuss] OpenProject Work Packages Workflow
Hi All, Sorry if I'm missing context since I'm new and just starting to read the discussion. I'm a product manager and I can help with some of the terminology.Caveat: Terms are generally flexible, so go with whatever works. Regarding Milestones they're generally meant for big events (i.e. launches or when you complete a suite of inter-related features) wherein you take stock and review work and see if changes are needed. They're sometimes time dependent (like after 2 months or after 4 sprints) but it depends on what measure works best. As for Epics, they are user stories but more general and vague, that can cover a lot of functionality. Think of it like an umbrella user story that has user stories beneath it. For example, a checkout process might be an epic, while shopping cart, address form, payment processor, and confirmation e-mail would be user stories under that epic. Epics are used to get a general idea of the scope/priority of the request without breaking everything down.- As for the why it should be explained as part of the User Story. The general form of a user story is, As a (actor/state), I want to (function) so that I can/because I want to (why).Date: Wed, 10 Feb 2016 12:10:40 -0800 From: br...@snowdrift.coop To: discuss@lists.snowdrift.coop Subject: Re: [Discuss] OpenProject Work Packages Workflow On Sat, Feb 06, 2016 at 06:38:24AM -0600, Jason Harrer wrote: > > 1) Changing the Milestone work package type is indeed an option. > The reason I chose to create the separate one is because a Milestone > in OP is intended to be kind of like a tag is in git: It marks a > certain point in time. Once we hit the milestone, we just mark it > on the timeline and move on. If we change the Milestone to track > all the work to reach the milestone, that would take away the > "tagging" capability. This strikes me as a win, but it is very likely that I don't understand why such a tag would be useful. My rationale is: won't we be able to see when a work package is done by seeing when all its sub-work-packages are done? > 2) Your response indicated ideas that I probably would have considered > Epics instead of User Stories, and that's based on what I read at > http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes. My reading of Scrum literature leads me to believe that "epic" is an adjective applied to user stories. When I use "epic" as a noun, it is just shorthand for "epic user story". That's why I wasn't sure we needed both. However, one thing lacking in Scrum is keeping track of "why" for tasks. It probably does make sense to keep the two types so it's possible to see where a user story comes from. ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Discuss] OpenProject Work Packages Workflow
On Sat, Feb 06, 2016 at 06:38:24AM -0600, Jason Harrer wrote: > > 1) Changing the Milestone work package type is indeed an option. > The reason I chose to create the separate one is because a Milestone > in OP is intended to be kind of like a tag is in git: It marks a > certain point in time. Once we hit the milestone, we just mark it > on the timeline and move on. If we change the Milestone to track > all the work to reach the milestone, that would take away the > "tagging" capability. This strikes me as a win, but it is very likely that I don't understand why such a tag would be useful. My rationale is: won't we be able to see when a work package is done by seeing when all its sub-work-packages are done? > 2) Your response indicated ideas that I probably would have considered > Epics instead of User Stories, and that's based on what I read at > http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes. My reading of Scrum literature leads me to believe that "epic" is an adjective applied to user stories. When I use "epic" as a noun, it is just shorthand for "epic user story". That's why I wasn't sure we needed both. However, one thing lacking in Scrum is keeping track of "why" for tasks. It probably does make sense to keep the two types so it's possible to see where a user story comes from. signature.asc Description: Digital signature ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Discuss] OpenProject Work Packages Workflow
Hi, Bryan - Thank you for that feedback. I realized as I was reading your response that you were out of the channel most of the week and I had forgot to put in this caveat in this e-mail: I intentionally set it up as detailed as I could think of, realizing that it probably would be overkill for Snowdrift.coop. The intent behind that was to let people see it used fully and try to determine what we *don't* need, as opposed to trying to go too basic and having people say "I think it needs something more, but I can't figure out what." That being said, I totally appreciate everything that you said, and I'm inclined to agree on most of it. It definitely needs to be scaled back. Here's my feedback on the few things that I'd like for you (and others) to ponder a bit more: 1) Changing the Milestone work package type is indeed an option. The reason I chose to create the separate one is because a Milestone in OP is intended to be kind of like a tag is in git: It marks a certain point in time. Once we hit the milestone, we just mark it on the timeline and move on. If we change the Milestone to track all the work to reach the milestone, that would take away the "tagging" capability. That being said, I personally don't care what the work package types are called. If you prefer Milestone to be the top level, here would be my proposal: 1. Rename the current Milestone work package type to "Tag" 2. Rename the current Phase work package type to "Milestone" (or some other term that we agree on) 3. Delete the Release work package type 2) Your response indicated ideas that I probably would have considered Epics instead of User Stories, and that's based on what I read at http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes. There's a bunch of additional defining that goes on beyond "I can pledge artificial money to projects to see how the mechanism works." What page will the pledging options be on? How will the user get to that page? Granted, for that example, I think we already have answers to those items, but the point is that by defining individual tasks in a User Story (e.g. "User clicks clicks on 'button x' to go to project page"), it will allow us to analyze each step and ensure that we have identified every task of work that will need to be performed. I'm concerned if we don't split out the high level "I want to do this" from the low level "This is each step that needs to be taken to get to this", we may miss something during the implementation. I'm not saying we definitely have to go the Epic + User Story route, but I'm just asking you to rethink it based on that explanation. You may be right: It could still be overkill for Snowdrift.coop. I'm just not fully convinced of that yet. So, let me know what ya'll think about these. Thanks!! - Jason On Fri, Feb 5, 2016 at 4:31 PM, Bryan Richter wrote: > On Fri, Feb 05, 2016 at 01:23:57PM -0600, Jason Harrer wrote: > > > > Here are my proposoals. > > > >- Work will be tracked in Releases > > - Release is a new Work Package type that I created. > > OpenProject was using it in their instance, and it made > > sense. It's a high level package to track all the cumulative > > work going on to get us to a certain point (in our current > > case, the alpha prototype) > > - We currently have more of a rolling release style, so either > > we can consider revising when we release updated code, or we > > can just consider the release done when the last piece is > > rolled out. I'm guessing the latter, but I just watned to > > point out the two options. > >- Each release would be laid out to have 5 different phases: > > > > > > - *Phase I: Requirements Gathering*: This will be when we > >determine all of the different components we want to work on > >for this release. Each component will yield its own Epic > >(which will be chlidren work packages under Phase I), tracked > >under Phase I. > > - *Phase II: Implementation Specifications*: (Note: Thinking of > >changing this to just Specifications or Solutioning): This > >is where the Epics are reviewed and broken down into User > >Stories (which will be children work packages under Phase > >II). From those User Stories, tasks will be created (as > >children under Phase III, even though they're created during > >Phase II). Note that the tasks will need to be assigned to > >the appropriate Circle/Group). > > - *Phase III: Implementation*: This will be where the tasks > >that were created in Phase II are actually worked on by the > >respective teams. Any code bugs during this step can be > >created and made children under Phase III to be worked before > >moving to testing. > > - *Phase IV: Testing: *This will be where the code is ran > >through auto
Re: [Discuss] OpenProject Work Packages Workflow
On Fri, Feb 05, 2016 at 01:23:57PM -0600, Jason Harrer wrote: > > Here are my proposoals. > >- Work will be tracked in Releases > - Release is a new Work Package type that I created. > OpenProject was using it in their instance, and it made > sense. It's a high level package to track all the cumulative > work going on to get us to a certain point (in our current > case, the alpha prototype) > - We currently have more of a rolling release style, so either > we can consider revising when we release updated code, or we > can just consider the release done when the last piece is > rolled out. I'm guessing the latter, but I just watned to > point out the two options. >- Each release would be laid out to have 5 different phases: > > > - *Phase I: Requirements Gathering*: This will be when we >determine all of the different components we want to work on >for this release. Each component will yield its own Epic >(which will be chlidren work packages under Phase I), tracked >under Phase I. > - *Phase II: Implementation Specifications*: (Note: Thinking of >changing this to just Specifications or Solutioning): This >is where the Epics are reviewed and broken down into User >Stories (which will be children work packages under Phase >II). From those User Stories, tasks will be created (as >children under Phase III, even though they're created during >Phase II). Note that the tasks will need to be assigned to >the appropriate Circle/Group). > - *Phase III: Implementation*: This will be where the tasks >that were created in Phase II are actually worked on by the >respective teams. Any code bugs during this step can be >created and made children under Phase III to be worked before >moving to testing. > - *Phase IV: Testing: *This will be where the code is ran >through automated tests, as well (potentially) as manual >review, to ensure that there are no foreseable bugs. Any >bugs found during this phase would be created as children >under Phase IV. > - *Phase V: Deployment: *This would be assigned to the Sys >Admin team to actually deploy the changes. > > > - If we stick with Rolling Release, I still believe the above >five phases could work, though each Epic could be in >different phases at different points. Then, I believe we'd >be probably be looking more at a kanban style workflow than >what I have listed above. I know there is the backlogs >section that we have that could be reviewed as well. > > > - I still need to figure out where we would want to store our >Feature Requests/WishList items. There are some proposals >I'd have on that: > > >1. We could create work packages with a type of Feature Requests, > which (at first) would not be linked to anything. When we > decide we want to use it, we could convert it to an Epic and > add it to the Release we're putting it in. >2. If we're not going to use the Backlogs section for anything > else, this could be a place to have them, which would at least > allow us more sorting capabilities than #1 (Though I would > have ideas for prioritization in #1 as well, just probably not > as quick and easy as a kanban board). >3. Wiki page on OP. Then, every member has access, organization > is a simple cut/paste, etc. > > I appreciate and welcome all comments, questions, brainstorming, etc. > Anything to help us move forward. Thanks!! > > - Jason (JazzyEagle) Hi Jason, thanks for taking the initiative on this. It's nice to have a starting point. For such a small team, a process that's too structured will just end up getting abandoned. Let's make sure the process is meeting our needs, and *only* meeting our needs. I already feel like we're caught up in fitting into some predefined framework instead of finding tools to fill our needs. So what are our needs? I will only speak of the WEBSITE project (not legal, not financial, not outreach). For that project, I posit that we only need milestones and user stories right now (for the next couple weeks). MILESTONES -- One need we have right now is keeping the ship pointed in the right direction. Getting to full functionality is crossing a big ocean and we need some stars to guide by. We've *already done this*, by breaking it down into milestones. I think we should keep that terminology. I know OpenProject makes the word "milestone" special and kinda useless by default, but that's a checkbox that can be unchecked: https://i.imgur.com/xCkexfp.jpg http://shovel.snowdrift.coop/projects/snowdrift/settings/types So, if we can, we should uncheck that box and use 'milestone' as our biggest-scope work package. Side
[Discuss] OpenProject Work Packages Workflow
Hello, all - I have been working on and started organizing into a Work Package workflow that I think will work for Snowdrift.coop. I'd like to get your thoughts and feedback on the layout as well as the proposed process. Please note that, even if we decide to move forward with this proposal, I'm most focused on what works best for the project and its members, so if we find something that doesn't work for us, we'll tweak it. I'm not expecting this first pass to be deemed perfect for our usage, but I had to start with something to get the conversation started. Here are my proposoals. - Work will be tracked in Releases - Release is a new Work Package type that I created. OpenProject was using it in their instance, and it made sense. It's a high level package to track all the cumulative work going on to get us to a certain point (in our current case, the alpha prototype) - We currently have more of a rolling release style, so either we can consider revising when we release updated code, or we can just consider the release done when the last piece is rolled out. I'm guessing the latter, but I just watned to point out the two options. - Each release would be laid out to have 5 different phases: - *Phase I: Requirements Gathering*: This will be when we determine all of the different components we want to work on for this release. Each component will yield its own Epic (which will be chlidren work packages under Phase I), tracked under Phase I. - *Phase II: Implementation Specifications*: (Note: Thinking of changing this to just Specifications or Solutioning): This is where the Epics are reviewed and broken down into User Stories (which will be children work packages under Phase II). From those User Stories, tasks will be created (as children under Phase III, even though they're created during Phase II). Note that the tasks will need to be assigned to the appropriate Circle/Group). - *Phase III: Implementation*: This will be where the tasks that were created in Phase II are actually worked on by the respective teams. Any code bugs during this step can be created and made children under Phase III to be worked before moving to testing. - *Phase IV: Testing: *This will be where the code is ran through automated tests, as well (potentially) as manual review, to ensure that there are no foreseable bugs. Any bugs found during this phase would be created as children under Phase IV. - *Phase V: Deployment: *This would be assigned to the Sys Admin team to actually deploy the changes. - If we stick with Rolling Release, I still believe the above five phases could work, though each Epic could be in different phases at different points. Then, I believe we'd be probably be looking more at a kanban style workflow than what I have listed above. I know there is the backlogs section that we have that could be reviewed as well. - I still need to figure out where we would want to store our Feature Requests/WishList items. There are some proposals I'd have on that: 1. We could create work packages with a type of Feature Requests, which (at first) would not be linked to anything. When we decide we want to use it, we could convert it to an Epic and add it to the Release we're putting it in. 2. If we're not going to use the Backlogs section for anything else, this could be a place to have them, which would at least allow us more sorting capabilities than #1 (Though I would have ideas for prioritization in #1 as well, just probably not as quick and easy as a kanban board). 3. Wiki page on OP. Then, every member has access, organization is a simple cut/paste, etc. I appreciate and welcome all comments, questions, brainstorming, etc. Anything to help us move forward. Thanks!! - Jason (JazzyEagle) ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
