Re: [Framework-Team] Re: Suggestion for adding Usecase information

2007-12-24 Thread Danny Bloemendaal


On 24 dec 2007, at 04:27, Hanno Schlichting wrote:


Danny Bloemendaal wrote:

After having waded through a big pile of plips I often (as a less
technical oriented member) had problems determining what the actual
usecase was that it was trying to solve. I would like to suggest  
(when
thechcnically possible) to add such a section in a plip. I'd like  
to see
a real-world usecase example (for the less technical ppl) what the  
plip

has to solve/support/whatever.
Something like:

Suppose someone wants to write a product that supports this or that.
Right now he has to do this or that to do this but with this plip in
place he only has to do such or so.

Right now, the Motivation section isn't exactly that. In most  
cases, the

author immediately dives into technical details.

I think it would help to have this addition? Or am I talking  
nonsense here?


+1, I think we have been bad both on the side of use-case centric and
integrator targeted information.



So what is needed? I think that only an extra header in the  
boilerplate text for a plip would be enough (and stress that writes  
fill it in of course). 


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team


Re: [Framework-Team] Re: Suggestion for adding Usecase information

2007-12-24 Thread Danny Bloemendaal


On 24 dec 2007, at 11:24, Martin Aspeli wrote:


Danny Bloemendaal wrote:

On 24 dec 2007, at 04:27, Hanno Schlichting wrote:

Danny Bloemendaal wrote:

After having waded through a big pile of plips I often (as a less
technical oriented member) had problems determining what the actual
usecase was that it was trying to solve. I would like to suggest   
(when
thechcnically possible) to add such a section in a plip. I'd  
like  to see
a real-world usecase example (for the less technical ppl) what  
the  plip

has to solve/support/whatever.
Something like:

Suppose someone wants to write a product that supports this or  
that.
Right now he has to do this or that to do this but with this plip  
in

place he only has to do such or so.

Right now, the Motivation section isn't exactly that. In most   
cases, the

author immediately dives into technical details.

I think it would help to have this addition? Or am I talking   
nonsense here?
+1, I think we have been bad both on the side of use-case centric  
and

integrator targeted information.

So what is needed? I think that only an extra header in the   
boilerplate text for a plip would be enough (and stress that  
writes  fill it in of course).


I think this fits well inside the Motivation box we already have.  
What's needed is a framework team that proactively asks people to  
fill in that information when submitting PLIPs, should it be  
insufficient.




I don't agree entirely. Motivation doesn't have to b a description for  
the usecase. Motivation is very general and can be a technical story  
only. A usecase is a 'normal'-people's description of what it tries to  
solve. It's almost like a scenario or a scriptive way to describe  
things. Motivation ís being used right now but hardly ever in the  
scenario/use-case kinda way. I don't think it is good idea to  
'correct' people if they didn't use Motivation is this way. It's  
better to have them write it from the start.


Danny
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team


[Framework-Team] Re: Suggestion for adding Usecase information

2007-12-24 Thread Martin Aspeli

Danny Bloemendaal wrote:

So what is needed? I think that only an extra header in the   
boilerplate text for a plip would be enough (and stress that  
writes  fill it in of course).
I think this fits well inside the Motivation box we already have.  
What's needed is a framework team that proactively asks people to  
fill in that information when submitting PLIPs, should it be  
insufficient.




I don't agree entirely. Motivation doesn't have to b a description for  
the usecase. Motivation is very general and can be a technical story  
only. A usecase is a 'normal'-people's description of what it tries to  
solve. 


Right. And IMHO no PLIP can be accepted if it doesn't address any real 
world use cases, hence that should be the core of the motivation.


It's almost like a scenario or a scriptive way to describe  
things. Motivation ís being used right now but hardly ever in the  
scenario/use-case kinda way.


Yep. We should be better at it.

I don't think it is good idea to  
'correct' people if they didn't use Motivation is this way. It's  
better to have them write it from the start.


Let me put it another way - I'd rather not have to make changes to PSC 
and deal with releases and migrations when we have a field that in one 
interpretation already meets the requirement. You can create however 
many fields you want with whatever titles you want - at the end of the 
day, it comes down to whoever fills the form in and what guidance they 
receive.


Martin

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


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team


Re: [Framework-Team] Re: preliminary results for PLIP selection call for votes!

2007-12-24 Thread Ricardo Newbery


On Dec 23, 2007, at 3:14 PM, Sidnei da Silva wrote:


To be clear, I believe the only -1 vote on #187 was primarily due to
some concerns about the shortage of detail in the PLIP text.  A
concern I share.  I'm hoping Sidnei fleshes out the details  
soon.  :-)


I would gladly answer any questions. The PLIP doesn't have much detail
because there ain't much to be detailed. The branch achieves the first
bullet under 'Proposal', and the third bullet was addressed and
released in a Zope release. The second bullet has resulted in some
research and I'm waiting for confirmation from Nate Aune that the
proposed fix for it works.

I have not addressed versioning because I didn't know there was any
concern about it. I saw the comment #3 but my assumption was that
whoever implemented versioning did it in such a way that it would
interact correctly with WebDAV, but did not have the time to verify
such assumption.

Feel free to ask more questions...




Thanks Sidnei,

What is the proposed (unconfirmed) fix for the second bullet (the OS  
X resource fork issue)?


Ric



___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team


Re: [Framework-Team] Re: preliminary results for PLIP selection call for votes!

2007-12-24 Thread Ricardo Newbery


Thanks again Sidnei,

[note to framework list:  let me know if I should take this  
discussion off list]


Maybe I'm missing something but there doesn't seem to be any reason  
to return a 404 (Not Found) or 403 (Forbidding) response.  Why not  
just silently discard the offending files, along with the  
configuration directive option?  Should be simpler to code.


Ric


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team


Re: [Framework-Team] Re: preliminary results for PLIP selection call for votes!

2007-12-24 Thread Sidnei da Silva
On Dec 24, 2007 6:36 PM, Ricardo Newbery [EMAIL PROTECTED] wrote:
 Thanks again Sidnei,

 [note to framework list:  let me know if I should take this
 discussion off list]

 Maybe I'm missing something but there doesn't seem to be any reason
 to return a 404 (Not Found) or 403 (Forbidding) response.  Why not
 just silently discard the offending files, along with the
 configuration directive option?  Should be simpler to code.

I have tried that approach and it failed in the past. If we behave
like the file has been succesfully created but just plain discard it,
Finder will expect it to be there, and if it get a 404 for a file that
was just created and it really expected to exist, it fails miserably.
Of course that could have changed in later versions of Finder. Sending
the 404/403 upfront is a saner and simpler approach which doesn't
break expectations on either side, IMO, and is more likely to work.

-- 
Sidnei da Silva
Enfold Systemshttp://enfoldsystems.com
Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team


Re: [Framework-Team] Re: preliminary results for PLIP selection call for votes!

2007-12-24 Thread Raphael Ritz

Ricardo Newbery wrote:


Thanks again Sidnei,

[note to framework list:  let me know if I should take this discussion 
off list]




No problem with me. You might want to consider cross-posting
or moving to plone-devel depending on the audience you want
to reach.

Just my 2 cents,

   Raphael


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team


Re: [Framework-Team] Official submission: PLIP 184, 200, 203 and 204

2007-12-24 Thread Raphael Ritz

Martin Aspeli wrote:

[..]



Cheers, and merry Christmas :)


Thanks for all your contributions and Merry Christmas,

   Raphael



Martin

[1] 
http://dev.plone.org/plone/browser/review/optilude-plipathon-184-200-203-204/REVIEW-NOTES.txt 







___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team