(Switching it to the ee-list)
On May 15, 2013, at 1:32 PM, Fabrice Florin fflorin@wikimedia.org wrote:
We may even want to try using it for remaining Echo tasks as well, not just for Flow.
I'm against changing things mid-stream. Let's see if Mingle works out for Flow (which hasn't started), and then we can see about its use elsewhere. Trello has worked out very well for E3 (as well as being valuable for the early development of Echo), and I'm not mandating E2 be backporting its use to Page Curation. ;-)
At the end of the day tools like Mingle, Bugzilla, Trello, Gerrit, wiki… are secondary documentation. Primary documentation is the code (git), followed closely by on-wiki for people who don't speak the language of code (when you think about it, that is part of our vision statement).
There is a cost to using secondary documentation, that means it has no value for its own sake, but only derives its value to the extent it helps in the creation of the primary forms.
Once a project has reached a certain level of maturity, any unnecessary documentation can be disposed of. Our process as it stands today doesn't allow us to be free of things like Gerrit, Bugzilla or wiki, but being able to let go of the unnecessary should be our goal. I like to think of these tools like writing on a napkin, it's okay at a certain time in the development process, but I wouldn't want everything we do to require a napkin doodling before implementation. ;-)
In the case of Mingle/Trello specifically these are closed source (possibly externally-hosted) software infrastructure pieces that we, as a Foundation, do not want to have an ongoing dependence on. During project creation and early development, the deadline-formation and other management tasks these afford are sometimes necessary in commercial space but do not really exist in all-volunteer open-source efforts, so some degree of dependence when there aren't open-source solutions becomes a necessary evil for that time in our project development. However, an ongoing dependence on these tools would become a wall prohibiting certain members of our community from being able to fully participate in, and that would be contrary to our commitment.
Take care,
terry
On 05/15/2013 04:55 PM, Terry Chay wrote:
Once a project has reached a certain level of maturity, any unnecessary documentation can be disposed of. Our process as it stands today doesn't allow us to be free of things like Gerrit, Bugzilla or wiki, but being able to let go of the unnecessary should be our goal. I like to think of these tools like writing on a napkin, it's okay at a certain time in the development process, but I wouldn't want everything we do to *require* a napkin doodling before implementation. ;-)
I agree the code should be self-documenting where possible, but coordination tools like Bugzilla, and various kinds of documentation (API docs like jsduck/PHPDoc, design docs, end user docs) are still necessary.
In the case of Mingle/Trello specifically these are closed source
(possibly externally-hosted) software infrastructure pieces that we, as a Foundation, do not want to have an ongoing dependence on. During project creation and early development, the deadline-formation and other management tasks these afford are sometimes necessary in commercial space but do not really exist in all-volunteer open-source efforts, so some degree of dependence when there aren't open-source solutions becomes a necessary evil for that time in our project development. However, an ongoing dependence on these tools would become a wall prohibiting certain members of our community from being able to fully participate in, and that would be contrary to our commitment.
I agree these tools are problematic for this reason. I understand why some people currently choose to use them, but the Foundation should investigate free alternatives that can meet our projects' needs.
Matt Flaschen
Matthew,
On May 15, 2013, at 3:29 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
In the case of Mingle/Trello specifically these are closed source
(possibly externally-hosted) software infrastructure pieces that we, as a Foundation, do not want to have an ongoing dependence on. During project creation and early development, the deadline-formation and other management tasks these afford are sometimes necessary in commercial space but do not really exist in all-volunteer open-source efforts, so some degree of dependence when there aren't open-source solutions becomes a necessary evil for that time in our project development. However, an ongoing dependence on these tools would become a wall prohibiting certain members of our community from being able to fully participate in, and that would be contrary to our commitment.
I agree these tools are problematic for this reason. I understand why some people currently choose to use them, but the Foundation should investigate free alternatives that can meet our projects' needs.
I don't want to vary from Mingle or Trello until it's proven for current projects, but you and Mark Holmquist have some incentive to try out alternative tools. We could probably start a labs instance and come up with a project that is defunct or not under active development yet that we can try out using a tool of your choosing. :-)
You guys have my okay to do that for something. :-)
Take care,
terry
On 05/15/2013 06:36 PM, Terry Chay wrote:
I agree these tools are problematic for this reason. I understand why some people currently choose to use them, but the Foundation should investigate free alternatives that can meet our projects' needs.
I don't want to vary from Mingle or Trello until it's proven for current projects, but you and Mark Holmquist have some incentive to try out alternative tools. We could probably start a labs instance and come up with a project that is defunct or not under active development yet that we can try out using a tool of your choosing. :-)
You guys have my okay to do that for something. :-)
Dan Andreescu and I (mostly him) actually setup (a while back) a Redmine instance for this purpose (with the goal of prototyping a nice FOSS solution). It seems to be currently down, but it's at http://redmine.instance-proxy.wmflabs.org/redmine/login .
Matt Flaschen
Redmine's a pain to install but pretty great once up. It has a very good plugin model through which we can add anything we need. Rob Lanphier and I discussed this a few times and came to the conclusion that Redmine + helping upstream fixes to plugins like http://www.redminebacklogs.net/ should cover all our use cases. We even have a migration path from Bugzilla as we can import all the historical data, even preserving bug numbers: https://github.com/ralli/bz2redmine
So if anyone decides to tackle this beast, count me in. The test redmine instance is back up (I think it goes down when the machine restarts - this is just my configuration mistake surely)
http://redmine.instance-proxy.wmflabs.org/redmine
On Wed, May 15, 2013 at 6:39 PM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
On 05/15/2013 06:36 PM, Terry Chay wrote:
I agree these tools are problematic for this reason. I understand why some people currently choose to use them, but the Foundation should investigate free alternatives that can meet our projects' needs.
I don't want to vary from Mingle or Trello until it's proven for current projects, but you and Mark Holmquist have some incentive to try out alternative tools. We could probably start a labs instance and come up with a project that is defunct or not under active development yet that we can try out using a tool of your choosing. :-)
You guys have my okay to do that for something. :-)
Dan Andreescu and I (mostly him) actually setup (a while back) a Redmine instance for this purpose (with the goal of prototyping a nice FOSS solution). It seems to be currently down, but it's at http://redmine.instance-proxy.wmflabs.org/redmine/login .
Matt Flaschen
On Wed, May 15, 2013 at 3:29 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
I agree these tools are problematic for this reason. I understand why some people currently choose to use them, but the Foundation should investigate free alternatives that can meet our projects' needs.
I'll reply in a bit more detail later, but just a quick note that most of the open source agile PM tools are pretty terrible, sadly. I've seen one that's potentially decent, Fulcrum, which is a Pivotal clone and may merit some investigation:
http://wholemeal.co.nz/projects/fulcrum.html -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
On Wed, May 15, 2013 at 1:55 PM, Terry Chay tchay@wikimedia.org wrote:
I'm against changing things mid-stream. Let's see if Mingle works out for Flow (which hasn't started), and then we can see about its use elsewhere. Trello has worked out very well for E3 (as well as being valuable for the early development of Echo), and I'm not mandating E2 be backporting its use to Page Curation. ;-)
Overall my experience with teams across the org has been:
- Using an agile PM tool becomes valuable at a team size of about 4+ developers. At smaller team sizes more lightweight tools often work better. - Mingle's worked well for most teams that have stuck with it and are at the above size. Mobile's made improvements to integrate Bugzilla reports into Mingle so that they automatically create cards, which reduces the transaction cost somewhat. - Mingle provides a lot of powerful features that make the effort invested in maintaining the cards worth it, including things like highly customized feeds, notifications and filters. It's also handy for remote folks to have a lot of visibility into a team's work. - Our Mingle instance is world-readable, so as long as you're comfortable navigating swimlanes you can figure out what's going on and have access to the same filters and views as everyone else.
Terry, Tomasz, Gayle and I have been talking about more practice-sharing across the org and are thinking about a workshop with Tom and Arthur around early July, where the Flow team could potentially be a pilot in learning from what mobile's been doing, and then decide which of those methods to adopt in practice.
Obviously I hear the concerns about free software, but like I said before, I have yet to see a tool that's actually carefully designed around agile development practices (as opposed to plugins being retrofitted into bug trackers and conventional PM tools). With that said, we've not mandated use of Mingle or any other tool because teams have to figure out what works for them. And continuous experimentation with tools available in the open source space is obviously good. :)
Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation