People can no longer post enhancement suggestions?

[Alexander Limi]

Excuse me, but I think this warrants a "WTF?"

Starting with:

http://dev.plone.org/plone/ticket/7336#comment:6

leading up to:

http://dev.plone.org/plone/ticket/7349#comment:1

Result: there's no longer an easy way to post an enhancement request for  
Plone. Being able to suggest these to the team in an easy way is essential  
for us, so we can get feedback and suggestions on how to improve.

Wichert, I'd appreciate some discussion before you go and change our  
processes in this way. ;)

--
Alexander Limi · http://limi.net


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Wichert Akkerman]

Previously Alexander Limi wrote:

> Excuse me, but I think this warrants a "WTF?"
>
> Starting with:
>
> http://dev.plone.org/plone/ticket/7336#comment:6
>
> leading up to:
>
> http://dev.plone.org/plone/ticket/7349#comment:1
>
> Result: there's no longer an easy way to post an enhancement request for  
> Plone. Being able to suggest these to the team in an easy way is essential  
> for us, so we can get feedback and suggestions on how to improve.

We have plips and mailinglists.

Wichert.

--
Wichert Akkerman <wichert@...>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[M.J. Pieters]

On Nov 12, 2007 9:44 PM, Wichert Akkerman <wichert@...> wrote:
> > Result: there's no longer an easy way to post an enhancement request for
> > Plone. Being able to suggest these to the team in an easy way is essential
> > for us, so we can get feedback and suggestions on how to improve.
>
> We have plips and mailinglists.

That's rather harsh. We used to have trac enhancement tickets too.
Different people like different ways of doing things, why can't they
use a trac ticket?

--
Martijn Pieters

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Wichert Akkerman]

Previously Martijn Pieters wrote:

> On Nov 12, 2007 9:44 PM, Wichert Akkerman <wichert@...> wrote:
> > > Result: there's no longer an easy way to post an enhancement request for
> > > Plone. Being able to suggest these to the team in an easy way is essential
> > > for us, so we can get feedback and suggestions on how to improve.
> >
> > We have plips and mailinglists.
>
> That's rather harsh. We used to have trac enhancement tickets too.
> Different people like different ways of doing things, why can't they
> use a trac ticket?

We assembled a whole pile of such requests that were just collecting
dust. If you browser through the issue tracker you'll see tickets with
enhancement requests that have been ignored for yaers.

I don't think we have a system at the moment. Just collecting them in a
bug tracker does not seem to be working.

Wichert.

--
Wichert Akkerman <wichert@...>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Hanno Schlichting-2]

Alexander Limi wrote:
> Result: there's no longer an easy way to post an enhancement request for  
> Plone. Being able to suggest these to the team in an easy way is essential  
> for us, so we can get feedback and suggestions on how to improve.

What Wichert did here was actually the common but never officially
discussed practice. We often told people in the past that certain
features requests require a PLIP or should be discussed on plone-dev,
and that the bug tracker was the wrong place for them.

For me the "official" story right now is that we don't have any
structured way to tell us about feature requests, other than posting
posts to mailing lists or to post blog entries about them.

This made me put the following on my to-discuss list for the Plone Core
Developer Summmit:

"Make better use of PLIP's? Have a more lightweight process to gather
ideas from developers and users (feature tracker)?"

But we can start the discussion on that now as well ;)

My main problem with using the bug tracker for feature requests like "I
want feature X" is that they will clutter up the listings without any
chance of ever being implemented / closed.

We can put "I want CalDAV, a REST interface to Plone or JSR-42 support"
in there but these are inherently different from simple bugs.

In my opinion the kind of features we are talking about here need more
of a discussion approach than a simple tracker comment listing. There
are use-cases to be found, areas identified where this would have an
impact on the Plone codebase, volunteers or money organized around those
ideas and decisions to be made of whether this should be a part of Plone
Core or better left to be an add-on.

For me Trac isn't the right tool for this and letting people enter
feature requests into our bug tracker will just give them a false
feeling of there requests being implemented - this is not how Open
Source works. Now I think we can aim at two things here:

1.) Either the simple option of using a new Trac instance or a simple
Wiki and just turn the list of things Alex currently compiles manually
for a new release (see for example
http://plone.org/products/plone/releases/4.0) into a simple tracker and
let other people add things there as well.

2.) Try to find a way to support the actual discussion process around
new features / ideas and structure it somehow.

I have no idea how exactly 2. would look like, but feel aiming at
something that supports the real needs would be more beneficial.

Let the discussion start ;)

Hanno


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli-2]

Wichert Akkerman wrote:

> Previously Alexander Limi wrote:
>> Excuse me, but I think this warrants a "WTF?"
>>
>> Starting with:
>>
>> http://dev.plone.org/plone/ticket/7336#comment:6
>>
>> leading up to:
>>
>> http://dev.plone.org/plone/ticket/7349#comment:1
>>
>> Result: there's no longer an easy way to post an enhancement request for  
>> Plone. Being able to suggest these to the team in an easy way is essential  
>> for us, so we can get feedback and suggestions on how to improve.
>
> We have plips and mailinglists.

True, but:

  - Mailing lists are great for discussion, but not good for tracking
requests. Unless someone picks up the item right away, we lose sight of
it in the noise.

  - Some people are scared to post to plone-dev - strange, but true, it
can be intimidating to non-developers.

  - PLIPs are more substantial documents, and can only be submitted by a
core developer. This is not just a matter of plone.org permissions: we
don't really want PLIPs for minor suggestions. They are there for big
lifts that we commit resources to, not random thoughts, and if we had
too many we'd end up losing them in the noise.

  - Developers may want to raise "enhancement" requests and assign to
themselves as personal to-do items.

However, we are not good at dealing with enhancement requests through
trac. If they get assigned to me, I'll normally either accept, reject or
try to post to plone-dev about it, but many are in a category that isn't
owned or just end up getting lost.

I'd like to have some discussion about the best way of dealing with such
small/incremental enhancement requests. Ideas?

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli-2]

Alexander Limi wrote:

> Excuse me, but I think this warrants a "WTF?"
>
> Starting with:
>
> http://dev.plone.org/plone/ticket/7336#comment:6
>
> leading up to:
>
> http://dev.plone.org/plone/ticket/7349#comment:1
>
> Result: there's no longer an easy way to post an enhancement request for  
> Plone. Being able to suggest these to the team in an easy way is essential  
> for us, so we can get feedback and suggestions on how to improve.
>
> Wichert, I'd appreciate some discussion before you go and change our  
> processes in this way. ;)

Speaking to Wichert on IRC, I think this was just a case of a little
over-zealous responsiveness and a desire to clean things up.

The category's back now, so let's have a proper discussion about how we
deal with these kind of requests and come up with a way forward.

Cheers,
Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Wichert Akkerman]

Previously Martin Aspeli wrote:

> Alexander Limi wrote:
> > Excuse me, but I think this warrants a "WTF?"
> >
> > Starting with:
> >
> > http://dev.plone.org/plone/ticket/7336#comment:6
> >
> > leading up to:
> >
> > http://dev.plone.org/plone/ticket/7349#comment:1
> >
> > Result: there's no longer an easy way to post an enhancement request for  
> > Plone. Being able to suggest these to the team in an easy way is essential  
> > for us, so we can get feedback and suggestions on how to improve.
> >
> > Wichert, I'd appreciate some discussion before you go and change our  
> > processes in this way. ;)
>
> Speaking to Wichert on IRC, I think this was just a case of a little
> over-zealous responsiveness and a desire to clean things up.
>
> The category's back now, so let's have a proper discussion about how we
> deal with these kind of requests and come up with a way forward.

Right, I'm sorry about that - I shouldn't have done that. I've been
unproductive and suffereing from an fizzing brain all day which isn't
helping.

In good news I did do a lot of the boring work of moving Plone 4 to
eggs. CMF and Archetypes are pretty much the only large bits remaining
now.

Wichert.

--
Wichert Akkerman <wichert@...>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[grahamperrin]

Hello all

First off: I didn't take things the wrong way, but thanks.

Ticket closure without further direction was a little odd, but more importantly:

* it was simple to re-open the ticket (compare to support systems that refuse such options)

* I gained _very rapid responses_ to my plea for direction.

Hanno Schlichting-2 wrote:

"Make better use of PLIP's? Have a more lightweight process to gather ideas from developers and users (feature tracker)?"

<http://plone.org/documentation/glossary/plip> read (for the first time) and understood.

Hanno Schlichting-2 wrote:

My main problem with using the bug tracker for feature requests like "I want feature X" is that they will clutter up the listings without any chance of ever being implemented / closed.

wichert wrote:

We assembled a whole pile of such requests that were just collecting dust.

Re clutter and dust: understood, and you have my sympathies.

At <http://code.google.com/p/macfusion/issues/list> we have what appears to be clutter -- but without bothering to filter by keyword/label, I *know* that many of these are not MacFusion issues.

By coincidence I'm helping the MacFusion developer to set up Trac. In that context my immediate highest-priority concern is:

Field population now broadly reflects the types of issue that are most often discussed.

If we have both MacFusion and plug-ins within a single Trac project, things could become very confusing in terms of milestones and versions.

On the other hand: if we have separate projects, then (at a glance) I see no easy way to move a ticket from one project to another.

Needs thought!

Highlight: I see no easy way to move a ticket from one Trac project to another. And an afterthought: if moving is possible, the ticket in its new location should remain reachable (redirected?) from its original URL.

(OT: beyond MacFusion and its plug-ins, the Trac there will inevitably include many non-defect issues that arise from normal/proper use of Apple Finder, and so on.)

wichert wrote:

If you browser through the issue tracker you'll see tickets with enhancement requests that have been ignored for yaers.

Without browsing: I'll _guess_ that the enhancement request collection in Plone Trac is not _immediately_ easy to use by someone with a specific interest...

Hanno Schlichting-2 wrote:

1.) Either the simple option of using a new Trac instance or a simple Wiki and just turn the list of things Alex currently compiles manually for a new release (see for example http://plone.org/products/plone/releases/4.0) into a simple tracker and let other people add things there as well.

A separate Trac instance may be appealing -- but then you have _yet another_ resource to consider when seeking/gathering information.

(OT: I wonder whether Trac search is configurable to return results from multiple projects within a single Trac instance. I'm on a Trac learning curve, I'll have my answer before long.)

If for Plone RFEs you _do_ opt for a separate Trac -- or a separate project within the Trac instance -- then you might distinguish clearly between the two, by use of visual style.

Back to issues of clutter and dust: these may be less daunting if you customise your existing Trac to suit a wider audience.

Focusing on <http://dev.plone.org/plone/report> why not add another report? --

* Enhancements

-- and if as I suspect you have a class of dusty enhancements that have been closed without action --

Hanno Schlichting-2 wrote:

the common but never officially discussed practice

-- then you might initially structure that 'Enhancements' report to include RFE tickets that are both open *and* closed.

(In due course I'll offer custom reports in MacFusion Trac ... in the meantime -- within the constraints of Google Code | Issues -- <http://code.google.com/p/macfusion/wiki/quick> serves my selfish needs there.)

I should add: I'm *not* a developer. Whilst I'm no longer scared of posting to this particular list, the lack of such skills normally makes me refrain from actively participating in developer forums. Human nature. So FWIW, re-focusing on the general subject of requests for enhancement, my own thoughts are that they should be openly invited to an area that is:

* non-daunting.

Probably stating the obvious: as so much work has gone into usability of Plone (and I vouch for its effectiveness), how about using Plone 3 + some valued product(s) as the friendly interface for gathering and categorising RFEs from end-users and developers?

Really, you can't beat suggestions -- however vague/dumb -- from end-users. My first training session yesterday (for fellow contributors to work-in-progress <http://centrim.cogapp.com/>) revealed a few issues that had been overlooked during development. By pleasant coincidence -- bringing the discussion full circle -- a perfectly ordinary uneducated end-user strayed from the subject of the training (adding a news item) to specifically quiz me about: calendar integration!

(OT from this thread: we're using iCalendar (SchoolTool) pending a likely migration to CalDAV (Apple iCal Server).)

Best regards
Graham

[Yves Moisan]

Wichert Akkerman a écrit :

> We assembled a whole pile of such requests ...
> I don't think we have a system at the moment. Just collecting them in a
> bug tracker does not seem to be working.
>

I wonder if a channel for quickly specifying enhancements/warts could be
useful ?  I'm reading the definitive Ubuntu book 2nd Ed these days and
those folks knew there were goinng to be warts in their first version,
so they called it Warty Warhog.  Now, I'm finding "warts" in my Plone 3
installation when I compare with what I had on 2.5.  I have written a
few of them on the plone-user list, but I don't want to clutter the list
with my own perceived warts yet at the same time I want Plone to work as
it used to.  Some of those plone 3 warts that I've come accross in no
particular order :

- Can't delete a page (see this morning on plone-user)

- Can't maximize a document in view mode (ar least with NuPlone); I find
it bothersome to be restricted to the middle pane only to view a
document in view mode; in Plone 2.5, I could hit the maximise button on
the top right of the document

- Selecting text in a page where one has write access invariably
triggers editing (I reported that before and I find this is a real pain
since I have to specifically "cancel" everytime I want to copy/paste
stuff from one document ot the other; I understand the rationale for
singl-click only, but the current implementation triggers a second click
anyhow ...)

I would very much like a channel (warts.plone.org ?) where those things
could be put with minimal fuss by normal (but honest!) users.  I would
feel like my comments are not lost in plone-user traffic and feel more
helpful with respect to the Plone community.

0.02,

Yves Moisan


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli-2]

Hanno Schlichting wrote:

> 1.) Either the simple option of using a new Trac instance or a simple
> Wiki and just turn the list of things Alex currently compiles manually
> for a new release (see for example
> http://plone.org/products/plone/releases/4.0) into a simple tracker and
> let other people add things there as well.

The problem is that this list is only useful if it's presented well and
thought through. A wiki would descend into noise very quickly.

> 2.) Try to find a way to support the actual discussion process around
> new features / ideas and structure it somehow.
>
> I have no idea how exactly 2. would look like, but feel aiming at
> something that supports the real needs would be more beneficial.

How about a new, archived, gmane'd mailing list called
feature-requests@...?

People could post pie-in-the-sky things there, and we could discuss. We
could then encourage people with good/sensible ideas to put them into a
PLIP format (still on the list, but similar headers and focus) that we
could then adopt into PLIPs.

I also find that having an "enhancement" category in trac is useful, in
that it can be used to track incremental improvements that should go
into releases. Report #7 in Trac is a to-do list for developers, so
being able to put stuff there's that's enhancements not just straight
bugs can be useful. However, we'd need to caveat or rename this so that
people didn't get the wrong idea.

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli-2]

Yves Moisan wrote:

Warts to me are bugs, so we have a way to track those.

> - Can't delete a page (see this morning on plone-user)

Bug - report in trac.

> - Can't maximize a document in view mode (ar least with NuPlone); I find
> it bothersome to be restricted to the middle pane only to view a
> document in view mode; in Plone 2.5, I could hit the maximise button on
> the top right of the document

Bug - report in trac.

> - Selecting text in a page where one has write access invariably
> triggers editing (I reported that before and I find this is a real pain
> since I have to specifically "cancel" everytime I want to copy/paste
> stuff from one document ot the other; I understand the rationale for
> singl-click only, but the current implementation triggers a second click
> anyhow ...)

Bug - but known issue, so no need to report.

> I would very much like a channel (warts.plone.org ?) where those things
> could be put with minimal fuss by normal (but honest!) users.  I would
> feel like my comments are not lost in plone-user traffic and feel more
> helpful with respect to the Plone community.

Asking on plone-user if you're not sure it's a bug is perfectly fine,
but we'll ask you to report them in trac if we think it's a bug,
otherwise we'll forget.

What we're talking about here, is requests for new features, which are
not "warts". :)

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Yves Moisan]

> Asking on plone-user if you're not sure it's a bug is perfectly fine,
> but we'll ask you to report them in trac if we think it's a bug,
> otherwise we'll forget.

Understood.  I went to the tracker to report one of the issues I pointed
out im my last message (cannot delete content) and the amount of results
sent back by the Trac search engine makes it impractical for people not
in the know to quickly determine whether a bug was reported already.  If
the search could be restricted by Plone release and ordered by date,
then maybe it could be easier to avoid bug reports replication?

Example.  Plone 3 comes out.  People see bugs/undesired UI changes.
Odds are people will experience the changes at the same time and
therefore start reporting bugs/questions/change requests at about the
same time.  I'm certainly not the only one who found out he couldn't
move objects in the contents view of a folder as of Plone 3, so if I had
an easy place to go to find out "bugs for the new version", I could :

1) be assured someone reported the bug
2) don't spend my time repeating a bug and spend a bug tracker's manager
time

I just want to feel confident I can effectively help Plone get better.

>
> What we're talking about here, is requests for new features, which are
> not "warts". :)

Right.

Thanx.

Yves


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Jon Stahl]

Martin Aspeli wrote:
> What we're talking about here, is requests for new features, which are
> not "warts". :)

I don't have any answers here, but I think these are important
questions, so thanks to Yves, Martin, Wichert and all of you for taking
them on.

I wonder... what is the process that, say, Ubuntu uses?  Is that
something we can learn from and/or adapt?

best,
jon

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Yves Moisan]

Martin Aspeli a écrit :

>> - Can't delete a page (see this morning on plone-user)
>
> Bug - report in trac.

I succeeded in deleting a folder just now.  I'll have to repeat the
error I got trying to delete a page.  When I get a clear idea of when it
happens, I'll file a bug.

>> - Can't maximize a document in view mode (ar least with NuPlone); I find
>> it bothersome to be restricted to the middle pane only to view a
>> document in view mode; in Plone 2.5, I could hit the maximise button on
>> the top right of the document
>
> Bug - report in trac.

IMO, that's a bug *in relation to* Plone 2.5 baseline functionality.
For new Plone users, that's a UI feature missing, not a bug.

Yves


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli-2]

Yves Moisan wrote:

>>> - Can't maximize a document in view mode (ar least with NuPlone); I find
>>> it bothersome to be restricted to the middle pane only to view a
>>> document in view mode; in Plone 2.5, I could hit the maximise button on
>>> the top right of the document
>> Bug - report in trac.
>
> IMO, that's a bug *in relation to* Plone 2.5 baseline functionality.
> For new Plone users, that's a UI feature missing, not a bug.

Regressions between versions are still bugs.

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[grahamperrin]

Yves Moisan wrote:

- Can't maximize a document in view mode [in Plone 3]

That seems to be <https://dev.plone.org/plone/ticket/7228> filed by me a month ago. Ah, I love coincidence.

Graham

[grahamperrin]

Martin Aspeli wrote:

How about a new, archived, gmane'd mailing list called [e-mail]?

For requests for enhancement/features:

As a complement to (not a substitute for) a ticket type in Trac, I do like the idea of a list. For broad discussion.

Nabble interface preferred.

That said, I did stumble on two occasions:

A) during the multi-step routine, from traditional list sign-up through to disabling delivery of e-mail

-- you can't make the instructions clearer than you have, I was simply dashing through things at the time, not paying greatest attention to the instructions

B) message rejected when I posted to a different area within the Plone forums

-- rights for http://www.nabble.com/General-Questions-f6742.html don't equate to rights for http://www.nabble.com/Plone-f6741.html in general

-- again, you can't make the instructions clearer, but the (few) steps for _each_ and _every_ one of the (eighteen) Plone forums ... not a great incentive, especially for people who may be:

* bothered by a bug
* bothered by the absence of a feature
* rushed or impatient, possibly as a result of the bother ;-)

All things considered, I far prefer the Trac approach:

1) search, or be guided by user-oriented reports

2) if my issue is not found: log in, new ticket.

=====================
User-oriented reports
=====================

Yves Moisan wrote:

the amount of results sent back by the Trac search engine makes it impractical for people not in the know to quickly determine whether a bug was reported already.  If the search could be restricted by Plone release and ordered by date, then maybe it could be easier to avoid bug reports replication?

 
At https://dev.plone.org/plone/report I suggest additional reports:

{nn} Tickets opened in the last nn days
{nn} Active tickets for Plone 3.x
{nn} Active tickets for Plone 2.5.x
{nn} Requests for enhancement

Of those four, the first and second should make it easier for me (and for Yves and others) to find issues that relate.

===============================
Exemplary use of Trac elsewhere
===============================

http://ircbrowse.com/channel/macfusion/20071115 for a very brief comparison of

* Plone use of Trac etc.
* Adium use of Trac etc..

Adium have, in at least one place (their blog) an unmistakable red alert approach to steering user comment/discussion away from areas where it's not preferred -- to areas where it's encouraged.

Whatever you decide, remember that your front page of Plone Trac directs visitors to search the issue tracker for existing feature suggestions :-)

Best regards
Graham

[Martin Aspeli-2]

Hi,

>> How about a new, archived, gmane'd mailing list called
>> feature-requests@...?
>>
>
> For requests for enhancement/features:
>
> As a complement to (not a substitute for) a ticket type in Trac, I do like
> the idea of a list. For broad discussion.

At least it widens the readership. Not many people read Trac RSS feeds. :)

> Nabble interface preferred.

If we set up a list, we'd add it to Nabble and Gmane of course.

> That said, I did stumble on two occasions:
>
> A) during the multi-step routine, from traditional list sign-up through to
> disabling delivery of e-mail
>
> -- you can't make the instructions clearer than you have, I was simply
> dashing through things at the time, not paying greatest attention to the
> instructions

This is a Nabble issue.

> B) message rejected when I posted to a different area within the Plone
> forums
>
> -- rights for http://www.nabble.com/General-Questions-f6742.html don't
> equate to rights for http://www.nabble.com/Plone-f6741.html in general

Yup. Rights are on a per-list basis. This is just how mailing lists
work, there's not much we can do about this.

> -- again, you can't make the instructions clearer, but the (few) steps for
> _each_ and _every_ one of the (eighteen) Plone forums ... not a great
> incentive, especially for people who may be:
>
> * bothered by a bug
> * bothered by the absence of a feature
> * rushed or impatient, possibly as a result of the bother ;-)

We can have the list allow anonymous posting, but we'd probably down in
spam after a while.

> All things considered, I far prefer the Trac approach:
>
> 1) search, or be guided by user-oriented reports
>
> 2) if my issue is not found: log in, new ticket.

The problem is more cultural than technical. Currently, the core
developers have too many bugs on their plate always, and feature
requests will inherently contain more "noise". Similarly, not many
people trawl Trac regularly. It may "feel" like a tracker submission has
a better chance of being considered, but the way we use Trac at the
moment, it's not the case. You're lucky if more than one person ever
looks at an enhancement ticket. Obviously that's broken. :)

> At https://dev.plone.org/plone/report I suggest additional reports:
>
> {nn} Tickets opened in the last nn days

Good, but only if someone regularly looks at that report.

> {nn} Active tickets for Plone 3.x
> {nn} Active tickets for Plone 2.5.x

We have active by milestone - same thing.

> {nn} Requests for enhancement

+1

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[grahamperrin]

Hello again

Martin Aspeli wrote:

We can have the list allow anonymous posting, but we'd probably down in spam after a while.

Anonymous, spam: bad.
-1

Authenticated, quickly and simply: good.
+1

Nabble issue.

Sure. I'm not griping to Plone about list subscription or Nabble routines/issues, merely drawing attention to the multiple and diverse steps that are required/recommended before input can be gained from new contributors.

> {nn} Active tickets for Plone 3.x
> {nn} Active tickets for Plone 2.5.x

We have active by milestone - same thing.

From my perspective, a very different thing: https://dev.plone.org/plone/report/6 is a _long_ list that relates to 2.5, 3, 3.1, 4 and the future.

I wish for a concise report that presents 3.0.x alone. Others may wish for 2.5.x alone.

> {nn} Tickets opened in the last nn days

Good, but only if someone regularly looks at that report.

Without a doubt, I'd look at this report before any other. Identify potential duplicates, that type of thing, leaving experienced developers more time to do what they do best.

That's not theory, it's a true reflection of how I already work with MacFusion issues, my first stop is always http://code.google.com/p/macfusion/issues/list?can=2&q=type:Defect&sort=-id+priority&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary

> {nn} Tickets opened in the last nn days

7 days might be good.

If it was me alone glancing through the most recent tickets, then I'd say 28 days, but as you have a wide/friendly community you can consider a tighter definition of 'recent'.

Key point for a report of this type, the list should be not too _long_. I have no idea how many new tickets you receive per week.

The problem is more cultural than technical.

Understood.

Allow the cultures to work in their preferred ways ...

... make best use of the infrastructure -- more user-friendly reports? -- and in time, the wider range of cultures (a broader, more proactive community of users) will become an asset.

Engage the widest range of users in ways that are a help to (not a disruption to) developers, and you'll have more time on your hands for the fun stuff :-)

Best regards
Graham