Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of Alex.Huang@citrix.com
 designates 66.165.176.63 as permitted sender)
From: Alex Huang <Alex.Huang@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Fri, 14 Dec 2012 10:39:34 -0800
Subject: RE: [DISCUSS] new workflow for new features....
Thread-Topic: [DISCUSS] new workflow for new features....
Thread-Index: Ac3aIO13IXG3R0QCSx+STiYUERV7+QAB3w7g
Message-ID: 
 <B1DF26ECC0458748AC97CECE2DA98D41012FA334EBC3@SJCPMAILBOX01.citrite.net>
References: 
 <B1DF26ECC0458748AC97CECE2DA98D41012FA334EB42@SJCPMAILBOX01.citrite.net>
 <CAKprHVYrZVBZfFVsPTUG_99y2H3a9Ug+oKrH0ja1rzaE+aemQQ@mail.gmail.com>
In-Reply-To: 
 <CAKprHVYrZVBZfFVsPTUG_99y2H3a9Ug+oKrH0ja1rzaE+aemQQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

>=20
> So what does this mean for a user requesting a feature or enhancement in
> Jira?
>=20
> User $foo may want CloudStack to provision coffee via IPMI, but they
> may also not have the ability to write that feature, but want to ask
> for it. Do they also need to bring it to the list? It seems very
> developer-centric, which isn't necessarily bad, but don't want to make
> users feel like their is a huge barrier to contributing to a feature
> discussion.
>=20

Don't assume the person performing the DISCUSS part of the work is the same=
 person as the one performing the PROPOSE part of the work.  They can be bu=
t they don't need to be.  The end user can definitely conduct the DISCUSS p=
art of the issue.

This is beneficial in several ways.

For the end user:
- Like I said in an earlier email can setup their own filters and check on =
the issues they are interested in.
-They can also create the issue and lead the DISCUSS portion of the feature=
 creation.
- Users can vote on the importance of a feature and that vote doesn't get l=
ost because a user doesn't participate on -dev or just didn't see it on -de=
v.

For the release manager:
- A release manager should look through the list and just ask if new featur=
es in DISCUSS status can actually be in their release. =20
- They can also bring up to the mailing list issues that are in the PROPOSE=
 list and ask if there are any takers.  If not, it then gets dropped out of=
 that release.

Developers:
- Can keep track of issues they are interested in.
- Have a place to update what they think is the current status.

It basically converges on mailing list and Jira and we use wiki as a starti=
ng point for end users to refer to these two places.  It's actually harder =
to start up but I think it will be easier to maintain in the long run.

--Alex