Smalltalk › Pharo › Pharo Smalltalk Developers

Beyond resolving a case

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Sergio Fedi

Beyond resolving a case

How do we state and/or document that further work is needed after a Case?

For example, some things I had in mind after finishing this case:

While adding the About comment for the Versionner tool I've found that the About should be modeled (at least to encapsulate the about text and the about window title, but maybe also for other information such as the purpose of the tool, the author, external link, further reading, etc).

Should we generate a test for this About behaviour ?

Should we move the About functionality up in the hierarchy and integrate it more with the classes used to make Tools?

I added a method that answers the tool name (as opposed to the tool class name, usually used in the About title)

and I found out there was another implementor on another Tool, but which I didn't understand the relationship with the Versionner.

Is there something that could be done? Maybe make an abstract method?

Is there a place where to put all these comments and questions/comments/ramblings?

If there is, where?

CyrilFerlicot

Re: Beyond resolving a case

Hi,
for those kind of things you can start discussions on the mailing list
and if the others find it good you can open new entry on fogbugz. If
you plan to do it you can assign it to you, if you don't have the time
you can assign it to "everyone".

On 4 May 2015 at 02:23, Sergio Fedi <[hidden email]> wrote:

> How do we state and/or document that further work is needed after a Case?
>
> For example, some things I had in mind after finishing this case:
>
> While adding the About comment for the Versionner tool I've found that the
> About should be modeled (at least to encapsulate the about text and the
> about window title, but maybe also for other information such as the purpose
> of the tool, the author, external link, further reading, etc).
>
> Should we generate a test for this About behaviour ?
>
> Should we move the About functionality up in the hierarchy and integrate it
> more with the classes used to make Tools?
>
> I added a method that answers the tool name (as opposed to the tool class
> name, usually used in the About title)
> and I found out there was another implementor on another Tool, but which I
> didn't understand the relationship with the Versionner.
> Is there something that could be done? Maybe make an abstract method?
>
> Is there a place where to put all these comments and
> questions/comments/ramblings?
> If there is, where?

--
Cheers
Cyril Ferlicot

Sergio Fedi

Re: Beyond resolving a case

I understand, thanks for the answer.

Ben Coman

Re: Beyond resolving a case

In reply to this post by Sergio Fedi

On Mon, May 4, 2015 at 8:23 AM, Sergio Fedi <[hidden email]> wrote:

How do we state and/or document that further work is needed after a Case?

If there are specific tasks you are already sure should be done, just open another ticket. If your not sure, discussion is best on the mail list - you'll get more opinions :).

btw, If you reference your original case like "Case 12345" you'll get a hotlink to it.

For example, some things I had in mind after finishing this case:

While adding the About comment for the Versionner tool I've found that the About should be modeled (at least to encapsulate the about text and the about window title, but maybe also for other information such as the purpose of the tool, the author, external link, further reading, etc).

Should we generate a test for this About behaviour ?

Probably, but I'm not sure of the convetions for gui testing. Maybe some sub parts.

Should we move the About functionality up in the hierarchy and integrate it more with the classes used to make Tools?

Note sure. I haven't had a chance to look at it yet -- but this reminds me that I've seen several places where the class comment is copied to an About window. Avoids having to synchronise. Would that be compatible with your implementation? Although probably there are times when the class comment is too much for and About. Maybe it defaults to the class comment - which means we get some About information for free, and maybe a convention to identify and <about>me</about> part of the class comment ?

I added a method that answers the tool name (as opposed to the tool class name, usually used in the About title)
and I found out there was another implementor on another Tool, but which I didn't understand the relationship with the Versionner.
Is there something that could be done? Maybe make an abstract method?

Not that I'll know the answer, but it would help to be more specific about the other method.

Is there a place where to put all these comments and questions/comments/ramblings?
If there is, where?

These are probably best to start on the mail list. Then copy pertinant parts to any issues created.

cheers -ben

Sean P. DeNigris

Re: Beyond resolving a case

Administrator

Ben Coman wrote

> *Is there a place where to put all these comments and questions/comments/ramblings?*
> *If there is, where?*

These are probably best to start on the mail list. Then copy pertinant parts to any issues created.

Also, for really thorny issues, you can build a list of what you learn in a doc at https://github.com/pharo-project/pharo-workingRoadmaps . I'm doing this for TxText...

Cheers,
Sean