We tried a wiki. It didn't work.

Andrei

On 1/19/12 8:26 AM, Robert Clipsham wrote:
> Given that this hasn't made much progress, perhaps a simple wiki page would do for now? It could look something like:
>
> = Task List =
>   * Link to task 1 wiki page
>   * Link to task 2 wiki page
>
> = dmd 2.058 =
>   Feature/bug freeze/beta 1 date: 12/3/4
>   Estimated release date : 4/3/2
>   * Link to task 1
>
> = Task 1 wiki page =
>   * Discussion at <link>
>   * Related bug: <link>
>
> And so on. It's obviously not the fanciest solution, it doesn't need any new tools though and it does the job.
>
> On 17 January 2012 15:19, Andrei Alexandrescu <andrei at erdani.com <mailto:andrei at erdani.com>> wrote:
>
>     Hello,
>
>
>     Walter and I were thinking of considering a sort of project planning
>     software, i.e. one that tracks high-level tasks, goals, and milestones.
>
>     Currently we have bugzilla for issue tracking, which is good for
>     bugs and small enhancement requests. Then we have github which is
>     excellent for revision tracking and such.
>
>     What we currently lack is a sort of a higher level tool that helps
>     us make plans together, order work items by urgency and importance,
>     and share with the community what our goals and milestones are.
>
>     Would you want to use such a tool, assuming of course it actually
>     helps us? And, before I start asking around, do you know of such a tool?
>
>
>     Thanks,
>
>     Andrei
>     _________________________________________________
>     dmd-internals mailing list
>     dmd-internals at puremagic.com <mailto:dmd-internals at puremagic.com>
>     http://lists.puremagic.com/__mailman/listinfo/dmd-internals
>     <http://lists.puremagic.com/mailman/listinfo/dmd-internals>
>
>
>
>
> --
> Robert
> http://octarineparrot.com/
>
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Thu, Jan 19, 2012 at 6:27 AM, Andrei Alexandrescu <andrei at erdani.com> wrote:
> We tried a wiki. It didn't work.
>
> Andrei

The only Phobos Dev I've seen edit the Wiki consistently has been Don. If no one is going to attempt to use it, what makes a new tool something everyone will use? It is not like the Wiki was being used and everyone was, "damn, I wish it had ___ feature." No one was using to even get annoyed with lack of X.

In this group lots have signed up to trillo, you have even started doing some task lists. Create an organization and publicize your list. You've given up because Walter is on board yet, but if the community actually starts to use it and coordinate, with it, Walter would be in the wrong to ignore that.

Frankly the only place I've seen collaboration has been these forums and the newsgroup. Both of which need someone to extract the important details and put them someplace such as a Wiki or trillo. I don't think trillo will help with organization if people don't organize it.

On 1/19/12 9:26 AM, Jesse Phillips wrote:
> On Thu, Jan 19, 2012 at 6:27 AM, Andrei Alexandrescu<andrei at erdani.com>  wrote:
>> We tried a wiki. It didn't work.
>>
>> Andrei
>
> The only Phobos Dev I've seen edit the Wiki consistently has been Don.

Walter, Bartosz and I tried using the wiki in the past. It was a complete failure.

> In this group lots have signed up to trillo, you have even started doing some task lists. Create an organization and publicize your list. You've given up because Walter is on board yet, but if the community actually starts to use it and coordinate, with it, Walter would be in the wrong to ignore that.

I honestly am giving up on this. I won't even look at other suggested products. There seems to be no shared vision of what kind of organization we need and even no consensus that we need better organization. To summarize my understanding:

1. Walter is (a) opposing trello, (b) not enthusiastic about changing much, (c) working kindly on particular examples discussed here (e.g. the oldest bugs).

2. Don is already organized in his approach to fixing bugs and doesn't think adding some project planning software would help.

3. Brad's opinion is that we're having a social issues that tools can't solve, and brings as evidence the fact that we don't use all features of our existing tools. Brad is not a strong participant in terms of code but is a key contributor of logistics and infrastructure.

4. Kenji is too gentleman to participate. I personally think his work is so awesome, if anything I'd be afraid the introduction of whatever tools to disrupt it in any way.

5. Leandro has the strong opinion that we don't need additional tools. He's not a massive participant to D but I mention this because he argues his point very passionately. I'm looking forward to equal passion in participation to D itself.

6. A few others thought they'd give it a whirl and joined trello. We have a project there with two items and a few tumbleweeds.

Given this state of affairs, it's very unlikely we're poised to operate a change of significant impact.


Andrei

On 1/18/12 11:10 PM, Martin Nowak wrote:
> This one seems way more mature, less simplistic and they can even handle mouse scrolling.
>
> http://flow.io
> http://flow.io/whats_new.html
> http://flow.io/plans.html
>
> It's not free but:
> "We support open-source projects. If you manage one, you can get a free
> plan with unlimited users. Please contact us for details."

Thanks for the pointer. Just to clarify - I won't be looking into this at this time.

Andrei

Le 2012-01-19 ? 11:02, Andrei Alexandrescu a ?crit :

> I honestly am giving up on this. I won't even look at other suggested products. There seems to be no shared vision of what kind of organization we need and even no consensus that we need better organization. To summarize my understanding:
> 
> 1. Walter is (a) opposing trello, (b) not enthusiastic about changing much, (c) working kindly on particular examples discussed here (e.g. the oldest bugs).
> 
> 2. Don is already organized in his approach to fixing bugs and doesn't think adding some project planning software would help.
> 
> 3. Brad's opinion is that we're having a social issues that tools can't solve, and brings as evidence the fact that we don't use all features of our existing tools. Brad is not a strong participant in terms of code but is a key contributor of logistics and infrastructure.
> 
> 4. Kenji is too gentleman to participate. I personally think his work is so awesome, if anything I'd be afraid the introduction of whatever tools to disrupt it in any way.
> 
> 5. Leandro has the strong opinion that we don't need additional tools. He's not a massive participant to D but I mention this because he argues his point very passionately. I'm looking forward to equal passion in participation to D itself.
> 
> 6. A few others thought they'd give it a whirl and joined trello. We have a project there with two items and a few tumbleweeds.
> 
> Given this state of affairs, it's very unlikely we're poised to operate a change of significant impact.


The problem with settings milestones is that everyone need to feel constrained by them, otherwise they are meaningless. More generally, what's needed is a way to take decisions and have everyone accept them. But before agreeing on a solution, the problem needs to be understood by everyone.

My understanding is that there is so many problems to fix everywhere that everyone is focussing on a small aspect and no one really get the whole. Like a giant castle that need to be repaired and extended, someone needs to draw a high-level map of it and then mark all the problematic areas and those that need to be built. Once you have that map you can plan a roadmap.

Is bugzilla providing a good enough overview? Would it work better with another tool? Maybe, maybe not. That's not important: pick the tool you want and try to draw an accurate overview of all aspects of the language, making everything that needing a fix or further development. Pick a drawing program if you need to. What's important to make the biggest flaws stand out. Once everyone can visualize the big picture, it'll be much easier to have everyone agree to a roadmap.

So adding a new tool is not the point of the exercise. The point is to have a better overview, a better understanding, so better decisions can be taken and agreed by everyone, and thus acted upon.

Sorry if I stated the obvious.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

Andrei Alexandrescu, el 19 de enero a las 08:14 me escribiste:
> >No, I'm just telling you about counter-examples. That's all I need to refute your reasoning :) (about the **need** for a new tool to get better organization, again, I do agree that we need better organization to grow, I don't agree about the means to get the better organization).
> 
> Well what means do you propose? You did little more in this discussion than contradicting things I said.

Taking more advantage of the tools we have now, like bugzilla. As Brad said there are plenty of features we are not using which can greatly improve the organization. We also have the mailing lists and github already. I think making the information more sparse will not contribute to organization.

Yo need a roadmap, use bugzilla's milestones. You need priorities, use bugzilla priorities. You need a big task that is composed by some other smaller tasks, use bugzilla's bug dependencies. The tools are there, and we can keep all the information together, making easier to do complex searches including both tasks and bugs.

> What steps can we take to get better at organizing D's development?

See above. I really do think we are very close in our positions. I think
the steps to be more organized we think we should take are pretty
similar. The big difference seems to be that you think that our current
tools are not enough and adding a new one will be a good thing and
I don't. Not only that, I fear it could make things even worse.

Also we need to improve the social skills, I also think that having more feedback is critical (hello Walter). Doesn't matter much where, we already have this and other lists, bugzilla and github. There is plenty of infrastructure to have good communications, I don't see how adding more structure would improve this.

But anyway, I think I exhausted all my arguments, so unless there is something extremely important to say, I'll just shut up (I liked this list better when there were no flamewars :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Se va a licitar un sistema de vuelos espaciales mendiante el cual, desde una
plataforma que quiz?s se instale en la provincia de C?rdoba, esas naves
espaciales van a salir de la atm?sfera, se van a remontar a la estrat?sfera
y desde ah? elegir el lugar donde quieran ir, de tal forma que en una hora
y media podamos desde Argentina estar en Jap?n, en Corea o en cualquier parte
del mundo.
	-- Carlos Sa?l Menem (sic)

Robert Clipsham, el 19 de enero a las 14:26 me escribiste:
> Given that this hasn't made much progress, perhaps a simple wiki page would do for now? It could look something like:
> 
> = Task List =
>  * Link to task 1 wiki page
>  * Link to task 2 wiki page
> 
> = dmd 2.058 =
>  Feature/bug freeze/beta 1 date: 12/3/4
>  Estimated release date : 4/3/2
>  * Link to task 1
> 
> = Task 1 wiki page =
>  * Discussion at <link>
>  * Related bug: <link>
> 
> And so on. It's obviously not the fanciest solution, it doesn't need any new tools though and it does the job.

I think bugzilla is way better for this than a wiki.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Be nice to nerds
Chances are you'll end up working for one

Andrei Alexandrescu, el 19 de enero a las 10:02 me escribiste:
> 5. Leandro has the strong opinion that we don't need additional tools. He's not a massive participant to D but I mention this because he argues his point very passionately. I'm looking forward to equal passion in participation to D itself.

Sometimes you can be such an asshole... You don't just ignore my work on D, but you even make fun of the fact that my work has been ignored. Is just so hard for me to control my impulse to just start cursing at you that you have no idea.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
El amor es como una reina ortop?dica.
	-- Poroto

On Jan 18, 2012, at 10:26 AM, Leandro Lucarella wrote:

> Alex, el 18 de enero a las 18:46 me escribiste:
>> It's simple: It usually goes in both. You file a bug/enhancement request/whatever on Bugzilla. People then post on Trello when they're working on it, adding comments/changes as they make progress.
> 
> So now to know the state or a bug I have to see 2 sites. Great!

This is annoying, but far from unusual.  For whatever reason, there simply aren't that many bug trackers that also have project management functionality, particularly once you're talking about free web-based apps.  DSource has Trac, and that's one of the few I'm aware of.  More important to me is that all of the D development tools (bug tracker, project tracker, wiki, etc) are placed front-and-center on the DPL webpage so there's no chance that anything could be missed.  Integration could be taken further via a blog or whatever, so project changes were automatically posted, and so on.  BugZilla is a foregone conclusion at this point, since it's already in place and integrated.  So the decision becomes whether we deal with the minimal project tracking functionality of BugZilla or add a new piece to the puzzle.

As an aside, I suppose it bears mentioning that one of our problems is simply that this is an open source project, so timelines and such can be difficult to project.  If I were working full-time on D I could make accurate statements about what I'd be working on, when it would be completed, etc.  As it is, when I have a spare moment for D I tend to jump on what seems to be the most important thing that specifically needs my input rather than working based on any sort of project plan.

On 1/19/2012 8:02 AM, Andrei Alexandrescu wrote:
> On 1/19/12 9:26 AM, Jesse Phillips wrote:
>> On Thu, Jan 19, 2012 at 6:27 AM, Andrei Alexandrescu<andrei at erdani.com>  wrote:
>>> We tried a wiki. It didn't work.

It hasn't worked since it's largely been a one man mission (go go Don!).   That's significantly different than "didn't" which implies that it also won't ever.  The wiki itself is essentially entirely a separate world from the D development world.  It contains (or did last time I explored it), a whole lot of interesting bits that really belong in bugzilla (and ultimately in the dlang website).  But that's a whole separate discussion so let's not get derailed by it right now.

> Walter, Bartosz and I tried using the wiki in the past. It was a complete failure.

Are you talking about the one I setup to record our notes back during the early days of the D2 dev cycle?  Yeah, it was much more of a note tracker than an effective design medium.  Face to face discussions were much more effective.

>> In this group lots have signed up to trillo, you have even started doing some task lists. Create an organization and publicize your list. You've given up because Walter is on board yet, but if the community actually starts to use it and coordinate, with it, Walter would be in the wrong to ignore that.
> 
> I honestly am giving up on this. I won't even look at other suggested products. There seems to be no shared vision of what kind of organization we need and even no consensus that we need better organization. To summarize my understanding:

I don't reach the same conclusion as you do.  I see definite consensus that we can and should do better, just not how to achieve it.  I really don't want to give up on getting more structure in the process.

> 3. Brad's opinion is that we're having a social issues that tools can't solve, and brings as evidence the fact that we don't use all features of our existing tools. Brad is not a strong participant in terms of code but is a key contributor of logistics and infrastructure.

That's a mis-framing of my opinion.  I think our issues are mostly social, which doesn't mean that they can't be changed, just that we need to realize that the changes are in behavior.  I also think that adding new tools should be secondary to taking advantage of the tooling we have.  However, if there's a tool that's perfect for our needs, we should certainly explore it.  I do suggest prioritize more use of our current tools over exploring others since we can do that RIGHT NOW with nearly zero effort.

> Given this state of affairs, it's very unlikely we're poised to operate a change of significant impact.

I think the best way to change is to just be bull-headed about it and change.  It's how bugzilla was started in the first place.  Walter used to 'track' bugs through posts in the digitalmars.d.bugs newsgroup.  I shuddered at how ineffective that was and set up bugzilla and pointed people at it.  It's now been about 6 years and we've had over 7300 bugs filed and issues aren't lost (other than in the noise of so many open bugs).

To that end, let's start planning the next release (not the upcoming one, that one's fairly close to ready to release, I think) with the tools available right now, specifically bugzilla.  I just deleted the 2.058 milestone and created 2.059.

I suggest that we create a roadmap.dd page (linked from relevant parts of the website, like the left-nav, probably the changelog and download pages as well) that starts to build a real roadmap and links to bugzilla search results.  File issues and sub-tasks for higher level todos.

Is it as good as it could possibly be, no.  Is it a lot better than we've had, yup.

As to Michel's comment that not everyone will follow it.  That's not super important (we shouldn't reject a fix that's in hand, that discourages participation).  Some people crave a bit of structure and will follow it without having to be asked, it just needs to be there.  A large portion of our potential user base definitely craves seeing that there's structure and stays away from the chaotic nature.  I can't blame them, and in-fact sympathize quite a bit.

What's important is that we have guidelines and policies for development and in particular gate releases based on those policies.

For example, the gcc team has a policy akin to:

    When the number of P1 bugs for a given release reaches 0 and
    P2 bugs reaches 100, the release branch is created.  At some
    point after that the release is cut (it's not when P2 bugs
    hits 0 since that's rarely achieved).

I'm not advocating that for DMD since our release cycles are about 5x more frequent than theirs and we don't, yet, really use branches much.  Baby steps.

Anyway, this email is long enough so I'll quit talking for the moment.

Later,
Brad