Re: [Discuss] OpenProject Work Packages Workflow

2016-02-12 Thread Stephen Michel
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

2016-02-12 Thread Bryan Richter
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

2016-02-12 Thread Bryan Richter
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

2016-02-12 Thread Aaron Wolf
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

2016-02-11 Thread Bryan Richter
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

2016-02-11 Thread charles

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

2016-02-11 Thread Bryan Richter
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

2016-02-11 Thread Stephen Michel


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

2016-02-06 Thread Jason Harrer
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