• Plone Cioppino Sprint discussion

  • thoughts toward a Cioppino sprint punch list

    from davisagli on Mar 15, 2012 01:17 AM
    Howdy sprinters! I'm super excited to see you all next week!
    
    It sounds like Steve, Liz, and Spanky have sprint logistics mostly under 
    control, so I wanted to chime in from the sprint goal perspective and 
    make sure we're all thinking at least a bit in advance about what we'd 
    like to work on. "A planned sprint is a productive sprint!" (Or at 
    least, thinking ahead makes sure that at least a little bit gets done 
    during the short breaks for work in between the strenuous eating, 
    drinking, and hot tubbing.)
    
    The overall theme of the sprint is improving Plone's approachability by 
    working on things like documentation and plone.org that are outward 
    facing and--if done right--a way to bring people into the community. 
    There are no hard and fast rules about what you're "allowed" to work on, 
    but hopefully we can all find something that a) benefits the Plone 
    community, b) gives us a chance to learn something, and c) is fun!
    
    Here are some ideas I have of things that might be good candidates for 
    things to work on. Please feel free to chime in with your own ideas!
    
    Documentation-related:
    1. Gardening and consolidating the developer manual. The collective docs 
    at http://collective-docs.readthedocs.org and the developer manual at  
    http://plone.org/documentation/manual/developer-manual have a lot of 
    overlap. There seems to be consensus that we should decommission the 
    latter and merge it into the former. The collective docs could also use 
    some editing, for grammar, accuracy, and to make sure things are 
    organized appropriately by subject.
    2. Garden the knowledgebase.
       a. Identify out of date articles, and either update them or move them 
    into an "attic" folder.
       b. Make sure that the intended ability for regular plone.org users to 
    edit KB articles actually works.
    3. Write new documentation for things that are underdocumented. Ideas:
       a. Dexterity tutorial and/or manual oriented toward people working 
    through the web (I want to work on this one. Would be great to be able 
    to work with someone else to help me figure out an outline for what 
    needs to be documented.)
       b. Manual describing Plone core development process
       c. Plone sysadmin guide
       d. plone.app.theming tutorial, including sections on how to install 
    and tweak an existing theme, and how to create a new theme, and misc 
    tips & tricks
    4. Explore options for letting the search feature on plone.org include 
    selected docs from readthedocs.org in the search results.
       a. Option 1: Spider the pages somehow, and add lightweight catalog 
    index entries with the right title & URL
       b. Option 2: solr
    5. Figure out what would need to happen to keep an archive of 
    Sphinx-based documentation for each Plone version.
    
    plone.org-related:
    
    1. Make sure it's running the latest version of Plone. (Alex Clark and I 
    are planning to work on this this weekend in hopes of having a fresh 
    plone.org ready to go for the sprint.)
    2. Revamp PSC so that it can automatically populate itself with all 
    packages with the Framework :: Plone classifier on PyPI.
    2. Attend to website-related tickets on trac.
    
    Other sources of ideas/tasks:
    1. Jon Stahl started a google doc which overlaps with the above ideas 
    but goes into more detail at 
    https://docs.google.com/document/d/1OMSwK7XlWSnfw4MsQ2vc8LOvMefm6WTbBOVtn7d2t7k/edit
    2. Trac tickets tagged with "cioppino": https://dev.plone.org/report/66
    
    How does this sound to others? What are all of you hoping to work on? 
    (It's okay if you don't know yet.)
    
    cheers,
    David
    
    Thread Outline:
  • Re: thoughts toward a Cioppino sprint punch list

    from spanky on Mar 15, 2012 05:51 PM
    On Mar 14, 2012, at 10:17 PM, David Glick wrote:
    
    > What are all of you hoping to work on?
    
    I just thought of another thing on this topic that really should be worked on:
    
    A directory of the documentation.  Even it seems like a bramble, it would be amazingly helpful to have a page that said, there are docs here, here, here and here.  It doesn't have to be a huge list (like the index of a book) but more like a map.  "Where to find documentations".
    
    I know that there's stuff scattered about, and while Google is helpful, sometimes it's just nice to see where the most likely places to look might be.
    
    --
    
    ~Spanky
    • Re: thoughts toward a Cioppino sprint punch list

      from davisagli on Mar 15, 2012 05:57 PM
      On Mar 15, 2012, at 2:51 PM, Tom Kapanka wrote:
      
      > 
      > On Mar 14, 2012, at 10:17 PM, David Glick wrote:
      > 
      >> What are all of you hoping to work on?
      > 
      > I just thought of another thing on this topic that really should be worked on:
      > 
      > A directory of the documentation.  Even it seems like a bramble, it would be amazingly helpful to have a page that said, there are docs here, here, here and here.  It doesn't have to be a huge list (like the index of a book) but more like a map.  "Where to find documentations".
      > 
      > I know that there's stuff scattered about, and while Google is helpful, sometimes it's just nice to see where the most likely places to look might be.
      > 
      
      You mean like http://plone.org/documentation? </snark>
      
      Or an updated version of http://plone.org/documentation/kb/read-documentation?
      
      
      • Re: thoughts toward a Cioppino sprint punch list

        from spanky on Mar 15, 2012 06:15 PM
        On Mar 15, 2012, at 2:57 PM, David Glick wrote:
        
        >> I know that there's stuff scattered about, and while Google is helpful, sometimes it's just nice to see where the most likely places to look might be.
        > 
        > You mean like http://plone.org/documentation? </snark>
        > 
        > Or an updated version of http://plone.org/documentation/kb/read-documentation?
        
        Yes exactly like that. Except updated!  And maybe with some bunnies.
        
        --
        
        ~Spanky
  • Re: thoughts toward a Cioppino sprint punch list

    from bakednotfried on Mar 18, 2012 01:15 AM
    Hey Folks,
    
    On Mar 14, 2012, at 11:17 PM, David Glick wrote:
    
    > How does this sound to others? What are all of you hoping to work on? (It's okay if you don't know yet.)
    
    
    This is my first sprint, and I'm not sure how things work, so I put down some thoughts about my background and where I might fit in.
    
    My formal CS training consists of two pascal classes back in the 80's--I believe they were literally CS101 and CS102. I was a network guy for about 20 years, taught high school math for a bit, and I've been making a living developing with plone/python for almost 5 years now. Mostly, I do plone 3; views, archetypes, buildout, paster, etc. 
    
    Since one of my passions is training and education, this sprint seems the perfect way to get involved and meet some people. 
    
    Believe it or not, I have almost 30 years of experience doing internet and technology training. Through all that time, I've been able to remember what it's like to be a newbie. We're all a newbie at something.  In some ways, I think I'm coming at this from that point of view.
    
    I like Tom's idea about a quick start area.
    
    I also like the idea of cleaning up some of the developer documentation we have, making it easier to read, bringing things up to date, etc.
    
    Looking forward to meeting y'all,
    Mike
    
    ps. Zoey says "Bunnies?! Yes, Bunnies!"
    
    
    
  • Re: thoughts toward a Cioppino sprint punch list

    from Elizabeth Leddy on Mar 15, 2012 01:14 PM
    On Mar 14, 2012, at 10:17 PM, David Glick wrote:
    
    > Howdy sprinters! I'm super excited to see you all next week!
    
    Thanks for getting this going!
    
    > It sounds like Steve, Liz, and Spanky have sprint logistics mostly under control, so I wanted to chime in from the sprint goal perspective and make sure we're all thinking at least a bit in advance about what we'd like to work on. "A planned sprint is a productive sprint!" (Or at least, thinking ahead makes sure that at least a little bit gets done during the short breaks for work in between the strenuous eating, drinking, and hot tubbing.)
    > 
    > The overall theme of the sprint is improving Plone's approachability by working on things like documentation and plone.org that are outward facing and--if done right--a way to bring people into the community. There are no hard and fast rules about what you're "allowed" to work on, but hopefully we can all find something that a) benefits the Plone community, b) gives us a chance to learn something, and c) is fun!
    > 
    > Here are some ideas I have of things that might be good candidates for things to work on. Please feel free to chime in with your own ideas!
    > 
    > Documentation-related:
    > 1. Gardening and consolidating the developer manual. The collective docs at http://collective-docs.readthedocs.org and the developer manual at  http://plone.org/documentation/manual/developer-manual have a lot of overlap. There seems to be consensus that we should decommission the latter and merge it into the former. The collective docs could also use some editing, for grammar, accuracy, and to make sure things are organized appropriately by subject.
    
    For me I think this is huge. It's kinda become a trash bin of advice.
    
    > 2. Garden the knowledgebase.
    >  a. Identify out of date articles, and either update them or move them into an "attic" folder.
    
    I think we should also make sure these are not spiderable. Google loves to fetch old KB articles with good keywords.
    
    >  b. Make sure that the intended ability for regular plone.org users to edit KB articles actually works.
    
    It doesn't. I don't know what happened with all those perms but I have been trying to help get people access for months now and almost all of them fail for one reason or another.
    
    I'm going to throw in...
    c. move everything that should be in readthedocs over to readthedocs. we need to firmly identify the purpose of docs on plone.org and docs on readthedocs. 
    d. turn commenting back on for everything in plone, add disqus to readthedocs. There is no easy way at the moment for people to ask questions or add comments. This was the biggest feedback I got from the munch conference - there is no way for people to say "is this best practice? "
    
    > 3. Write new documentation for things that are underdocumented. Ideas:
    >  a. Dexterity tutorial and/or manual oriented toward people working through the web (I want to work on this one. Would be great to be able to work with someone else to help me figure out an outline for what needs to be documented.)
    >  b. Manual describing Plone core development process
    >  c. Plone sysadmin guide
    >  d. plone.app.theming tutorial, including sections on how to install and tweak an existing theme, and how to create a new theme, and misc tips & tricks
    
        e. how to sanely create a form
    
    > 4. Explore options for letting the search feature on plone.org include selected docs from readthedocs.org in the search results.
    >  a. Option 1: Spider the pages somehow, and add lightweight catalog index entries with the right title & URL
    >  b. Option 2: solr
        
    2 cents: No one searches for docs in plone and its terrible searching through even our own database. I think the better strategy is to have a google search "plan".
    
    > 5. Figure out what would need to happen to keep an archive of Sphinx-based documentation for each Plone version.
    
    +100. That and/or come up with a way to mark things new and deprecated
    
    6. Document on how and where to document on plone.
      a. how to document new features (PLIPS)
      b. general guidlines for documentation
      c. recommended guidelines for documenting add-ons
    
    I actually think we should start there. Set a standard, and work on it the whole sprint.
    
    > 
    > plone.org-related:
    > 
    > 1. Make sure it's running the latest version of Plone. (Alex Clark and I are planning to work on this this weekend in hopes of having a fresh plone.org ready to go for the sprint.)
    > 2. Revamp PSC so that it can automatically populate itself with all packages with the Framework :: Plone classifier on PyPI.
    
    Is this task too big?
    
    > 2. Attend to website-related tickets on trac.
    > 
    > Other sources of ideas/tasks:
    > 1. Jon Stahl started a google doc which overlaps with the above ideas but goes into more detail at https://docs.google.com/document/d/1OMSwK7XlWSnfw4MsQ2vc8LOvMefm6WTbBOVtn7d2t7k/edit
    > 2. Trac tickets tagged with "cioppino": https://dev.plone.org/report/66
    > 
    > How does this sound to others? What are all of you hoping to work on? (It's okay if you don't know yet.)
    
    On top of all that, I would like to finish some documentation on 
    a. how to contribute bug fixes in detail
    b. how to develop a plip (ties into how to document)
    
    I would like to see most documentation tickets closed as well. Also, we need a doc team lead. I have some ideas and maybe I'll use this time to dupe encourage them to step up. I'd really like to spend my time on documentation and not PSC/plone.org this year. I think this is so much more pain for most people than the crappy bugs in the PSC/plone.org 
    
    Liz
    
    > 
    > cheers,
    > David
    > 
    > 
    > --
    > Archive: http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331788630739
    > To unsubscribe send an email with subject "unsubscribe" to cioppino-discussion@....  Please contact cioppino-discussion-manager@... for questions.
    > 
    
    
    • Re: thoughts toward a Cioppino sprint punch list

      from stevem on Mar 16, 2012 08:18 PM
      Just wanted to say that there was a *very* good reason why we turned off
      commenting when we did the last big PHC cleanup. Folks were trying to use
      commenting to ask questions, and many documents had pages and pages of "How
      do I do ..." with no replies to any of it.
      
      Somebody who contributes a document typically does not want to take
      personal responsibility for gardening the comments on that document for a
      few years. And, if the person who wrote the doc won't do it, who will?
      
      So, we wanted to create an atmosphere of "if a document is broken, fix it;
      if you've a question, submit it where lots of eyes will see it and someone
      may answer." I don't think we succeeded, but I'm pretty sure turning back
      on commenting is not the way to improve the situation.
      
      On Thu, Mar 15, 2012 at 10:14 AM, Elizabeth Leddy <camembert@...>wrote:
      
      > ...
      > d. turn commenting back on for everything in plone, add disqus to
      > readthedocs. There is no easy way at the moment for people to ask questions
      > or add comments. This was the biggest feedback I got from the munch
      > conference - there is no way for people to say "is this best practice? "
      
      
  • Re: thoughts toward a Cioppino sprint punch list

    from spanky on Mar 15, 2012 02:31 PM
    On Mar 14, 2012, at 10:17 PM, David Glick wrote:
    
    > Howdy sprinters! I'm super excited to see you all next week!
    
    
    Me too!   Lots of +1's below, I'll just add pertinent comments instead of "yes! yes!" everywhere.
    
    
    > It sounds like Steve, Liz, and Spanky have sprint logistics mostly under control, so I wanted to chime in from the sprint goal perspective and make sure we're all thinking at least a bit in advance about what we'd like to work on. "A planned sprint is a productive sprint!" (Or at least, thinking ahead makes sure that at least a little bit gets done during the short breaks for work in between the strenuous eating, drinking, and hot tubbing.)
    > 
    > The overall theme of the sprint is improving Plone's approachability by working on things like documentation and plone.org that are outward facing and--if done right--a way to bring people into the community. There are no hard and fast rules about what you're "allowed" to work on, but hopefully we can all find something that a) benefits the Plone community, b) gives us a chance to learn something, and c) is fun!
    > 
    > Here are some ideas I have of things that might be good candidates for things to work on. Please feel free to chime in with your own ideas!
    > 
    > Documentation-related:
    > 1. Gardening and consolidating the developer manual. The collective docs at http://collective-docs.readthedocs.org and the developer manual at  http://plone.org/documentation/manual/developer-manual have a lot of overlap. There seems to be consensus that we should decommission the latter and merge it into the former. The collective docs could also use some editing, for grammar, accuracy, and to make sure things are organized appropriately by subject.
    
    
    While I agree with this in principle, I think it reflects pretty poorly on a content management system that doesn't use itself for its documents (content).  I am not going to be a stickler about it, but I really think it's worth considering how this is perceived.  "Are We Not Plone?" ;-)
    
    
    > 2. Garden the knowledgebase.
    >  a. Identify out of date articles, and either update them or move them into an "attic" folder.
    >  b. Make sure that the intended ability for regular plone.org users to edit KB articles actually works.
    > 3. Write new documentation for things that are underdocumented. Ideas:
    >  a. Dexterity tutorial and/or manual oriented toward people working through the web (I want to work on this one. Would be great to be able to work with someone else to help me figure out an outline for what needs to be documented.)
    >  b. Manual describing Plone core development process
    >  c. Plone sysadmin guide
    >  d. plone.app.theming tutorial, including sections on how to install and tweak an existing theme, and how to create a new theme, and misc tips & tricks
    
    
    I have an idea that I would like to implement, with input and feedback from everyone of course.  Essentially I'd like to have one page which is a jumping off point for people brand new to Plone.    I call these "QuickStarts".  You're familiar with my installation quickstart already.  I've seen it help really frustrated people get off and running in under 30 minutes.  I'd like to write two or three more and have them done and presented in a "bam bam bam, you want to do these things" format.  The others are:
    
    - "So you want to make a form"
    - Subclassing a content type
    - Overriding a view/viewlet
    - Rolling a Plone theme w/Diazo
    
    I consider these different from "documentation" because they don't go into detail.  Consider the cooking metaphor.  You can buy a 500 page cooking book and learn all about the Maillard reaction and various types of metal used in knives and study flavor pairings, or you can follow a Cook's Illustrated recipe and have dinner. Now.  Sure, if you want to be a GOOD cook, you should learn how to break down a chicken, but often people just want to get up and running and feel a sense of accomplishment.
    
    I can't write these alone because they require a consensus of current best practices and I'm pretty sure I'm not following them!  Just like last Cioppino where I asked a lot of questions and wrote it all out and had it tested, I'd like to do the same this time, but I think I can work faster and get more done.  I've actually DONE all of the things and I have good working examples that I can work from and get feedback on how to do it right.
    
    I'd really like to push this kind of document up front to the user, and then we can link from within it to the "real" documentation that goes in depth and explains everything in detail.
    
    I also have seen a LOT of questions around migration and upgrading, so maybe we need to have something that is very clear on the process.
    
    Finally, without any animosity here... I would like a review of Martin's documentation specifically, simply because I have run across lots of things in it that didn't work or was simply steering people (me!) in the wrong direction.  Well, maybe not "wrong", but in directions that caused me pain and cross-eyed looks from others later.  I think the information is there, but it needs to be looked at to be sure A. it actually executes, B. is clear, and C. is the most straightforward way to  go about it.
    
    
    > 4. Explore options for letting the search feature on plone.org include selected docs from readthedocs.org in the search results.
    >  a. Option 1: Spider the pages somehow, and add lightweight catalog index entries with the right title & URL
    >  b. Option 2: solr
    > 5. Figure out what would need to happen to keep an archive of Sphinx-based documentation for each Plone version.
    > 
    > plone.org-related:
    > 
    > 1. Make sure it's running the latest version of Plone. (Alex Clark and I are planning to work on this this weekend in hopes of having a fresh plone.org ready to go for the sprint.)
    
    
    Speaking of which: last time we had big network issues when everyone tried to get the latest Plone.org and all eggs.  How should we prepare for this time?  Network drive? Shared eggs?  Download something in advance?
    
    Which also begs the question, who's bringing the hardware (wifi + router)?  I was thinking of buying a new AirPort extreme anyways...
    
    
    > 2. Revamp PSC so that it can automatically populate itself with all packages with the Framework :: Plone classifier on PyPI.
    > 2. Attend to website-related tickets on trac.
    > 
    > Other sources of ideas/tasks:
    > 1. Jon Stahl started a google doc which overlaps with the above ideas but goes into more detail at https://docs.google.com/document/d/1OMSwK7XlWSnfw4MsQ2vc8LOvMefm6WTbBOVtn7d2t7k/edit
    > 2. Trac tickets tagged with "cioppino": https://dev.plone.org/report/66
    > 
    > How does this sound to others? What are all of you hoping to work on? (It's okay if you don't know yet.)
    > 
    > cheers,
    > David
    > 
    > 
    > --
    > Archive: http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331788630739
    > To unsubscribe send an email with subject "unsubscribe" to cioppino-discussion@....  Please contact cioppino-discussion-manager@... for questions.
    > 
    
    
    • Re: thoughts toward a Cioppino sprint punch list

      from spanky on Mar 16, 2012 06:15 PM
      On Mar 16, 2012, at 1:06 PM, David Glick wrote:
      
      >> Finally, without any animosity here... I would like a review of Martin's documentation specifically, simply because I have run across lots of things in it that didn't work or was simply steering people (me!) in the wrong direction.  Well, maybe not "wrong", but in directions that caused me pain and cross-eyed looks from others later.  I think the information is there, but it needs to be looked at to be sure A. it actually executes, B. is clear, and C. is the most straightforward way to  go about it.
      > 
      > To be fair to Martin, a lot of the troubles I've observed you having were because you weren't trying to do exactly what Martin was describing, but trying to adapt it to meet additional requirements that you had (i.e. trying to get it to work without grok, or trying to get it to work with collective.z3cform.wizard). That the framework makes it hard to be successful at adapting the examples to new scenarios is certainly a problem with the framework, but blaming the docs seems unfair.
      
      
      Again, not trying to bag on Martin :-)  I recognize that he's done a ton of work and much of it is at least documented!  What I'm getting at here is that Martin's docs (and book) take you in a direction that, it turns out, is much a matter of opinion and personal style.  I realize that I wasn't doing exactly what he was describing, but nobody is ever going to do exactly what the example is.  If the example is straightforward enough and adaptable enough, anyone can take the base principle and apply it to their individual need.  As it stands right now, that leap is a chasm.  I found that (despite trying to avoid grok [because I don't grok it], and using the form Wizard) that in the end, many of the decisions and assumptions made by Martin in his book and docs cloud the issue at hand, confuse the novice, and are really unnecessary.  Another example, I was reading a particular doc that was so confusing because while the lesson at hand was about how to make a vocabulary, there was so much intertwined superfluous information about getting the portal management tool and getting a list of groups to make the list from, that in the end it was unclear what was the actual point of the lesson and what was irrelevant.  Simple, straightforward, stripped down examples of how to accomplish atomic tasks is what I would like to see.  I know it's all in there, it's just done Martin-Style.
      
      I swear when I was reading his book I almost picked up the phone to call him and say "Your next book? I'm your editor".  He needs an editor.  He's crazy smart, crazy skilled, I respect him a lot, but he's been doing it so long, it seems he's forgotten what it's like to not understand.
      
      That's my opinion, and I'm sticking to it! ;-)
      
      
      > That said, I think the Dexterity manual is probably due for some editing and confirming that things are still a) best practice and b) working. This is one thing I want to work on. If you have specific feedback on things that were wrong or misleading, please let me know.
      > 
      > cheers,
      > David
      > 
      > 
      > ----------		
      > David Glick
      > Web Developer
      > davidglick@...
      > 206.286.1235x32
      > 
      > The Engagement Party 2012. So much more fun than the wedding reception.
      > 
      > http://www.npoengagementparty.com
      > 
      > 
      
      
    • Re: thoughts toward a Cioppino sprint punch list

      from David Glick on Mar 16, 2012 04:09 PM
      On 3/15/12 11:30 AM, Tom Kapanka wrote:
      > I have an idea that I would like to implement, with input and feedback from everyone of course.  Essentially I'd like to have one page which is a jumping off point for people brand new to Plone.    I call these "QuickStarts".  You're familiar with my installation quickstart already.  I've seen it help really frustrated people get off and running in under 30 minutes.  I'd like to write two or three more and have them done and presented in a "bam bam bam, you want to do these things" format.  The others are:
      >
      > - "So you want to make a form"
      > - Subclassing a content type
      > - Overriding a view/viewlet
      > - Rolling a Plone theme w/Diazo
      >
      > I consider these different from "documentation" because they don't go into detail.  Consider the cooking metaphor.  You can buy a 500 page cooking book and learn all about the Maillard reaction and various types of metal used in knives and study flavor pairings, or you can follow a Cook's Illustrated recipe and have dinner. Now.  Sure, if you want to be a GOOD cook, you should learn how to break down a chicken, but often people just want to get up and running and feel a sense of accomplishment.
      >
      > I can't write these alone because they require a consensus of current best practices and I'm pretty sure I'm not following them!  Just like last Cioppino where I asked a lot of questions and wrote it all out and had it tested, I'd like to do the same this time, but I think I can work faster and get more done.  I've actually DONE all of the things and I have good working examples that I can work from and get feedback on how to do it right.
      >
      > I'd really like to push this kind of document up front to the user, and then we can link from within it to the "real" documentation that goes in depth and explains everything in detail.
      +1. In general, best practice seem to be to provide 3 main types of 
      documentation:
      1. A narrative manual. (Combining the collective docs and the existing 
      developer manual will be a good start at this.)
      2. Some quick starts/tutorials that focus on walking through the steps 
      in detail over explaining concepts in depth. An obvious thing to point 
      people to when they ask, "How do I get started with Plone?" (This is our 
      weakest area, and I'm a big fan of Spanky's proposal.)
      3. An API reference. (We're also weak here, but to be fair it's a 
      difficult challenge given how sprawling Zope and Plone are. Let's do 
      some brainstorming about this at the sprint.)
      > I also have seen a LOT of questions around migration and upgrading, so maybe we need to have something that is very clear on the process.
      >
      > Finally, without any animosity here... I would like a review of Martin's documentation specifically, simply because I have run across lots of things in it that didn't work or was simply steering people (me!) in the wrong direction.  Well, maybe not "wrong", but in directions that caused me pain and cross-eyed looks from others later.  I think the information is there, but it needs to be looked at to be sure A. it actually executes, B. is clear, and C. is the most straightforward way to  go about it.
      
      To be fair to Martin, a lot of the troubles I've observed you having 
      were because you weren't trying to do exactly what Martin was 
      describing, but trying to adapt it to meet additional requirements that 
      you had (i.e. trying to get it to work without grok, or trying to get it 
      to work with collective.z3cform.wizard). That the framework makes it 
      hard to be successful at adapting the examples to new scenarios is 
      certainly a problem with the framework, but blaming the docs seems unfair.
      
      That said, I think the Dexterity manual is probably due for some editing 
      and confirming that things are still a) best practice and b) working. 
      This is one thing I want to work on. If you have specific feedback on 
      things that were wrong or misleading, please let me know.
      
      cheers,
      David
      
      
      ----------		
      David Glick
       Web Developer
       davidglick@...
       206.286.1235x32
      
      The Engagement Party 2012. So much more fun than the wedding reception.
      
      http://www.npoengagementparty.com
      
      
      
      • Re: thoughts toward a Cioppino sprint punch list

        from mosx86 on Mar 16, 2012 04:29 PM
        +1 to Tom's QuickStart idea in general.
        
        +1 to an API reference.
        
        >
        > 3. An API reference. (We're also weak here, but to be fair it's a
        > difficult challenge given how sprawling Zope and Plone are. Let's do some
        > brainstorming about this at the sprint.)
        >
        >
        In my opinion, reviving api.plone.org should be high priority. Having had
        to work with other frameworks lately (like jquery and boto) it is immensely
        useful to be able to search and browse the API through the web.  I think
        the lack of a documented API is a huge turn off to new developers.
        
        Luke
        
        
    • Re: thoughts toward a Cioppino sprint punch list

      from Elizabeth Leddy on Mar 15, 2012 02:44 PM
      On Mar 15, 2012, at 11:30 AM, Tom Kapanka wrote:
      
      > 
      > On Mar 14, 2012, at 10:17 PM, David Glick wrote:
      > 
      >> Howdy sprinters! I'm super excited to see you all next week!
      > 
      > 
      > Me too!   Lots of +1's below, I'll just add pertinent comments instead of "yes! yes!" everywhere.
      > 
      > 
      >> It sounds like Steve, Liz, and Spanky have sprint logistics mostly under control, so I wanted to chime in from the sprint goal perspective and make sure we're all thinking at least a bit in advance about what we'd like to work on. "A planned sprint is a productive sprint!" (Or at least, thinking ahead makes sure that at least a little bit gets done during the short breaks for work in between the strenuous eating, drinking, and hot tubbing.)
      >> 
      >> The overall theme of the sprint is improving Plone's approachability by working on things like documentation and plone.org that are outward facing and--if done right--a way to bring people into the community. There are no hard and fast rules about what you're "allowed" to work on, but hopefully we can all find something that a) benefits the Plone community, b) gives us a chance to learn something, and c) is fun!
      >> 
      >> Here are some ideas I have of things that might be good candidates for things to work on. Please feel free to chime in with your own ideas!
      >> 
      >> Documentation-related:
      >> 1. Gardening and consolidating the developer manual. The collective docs at http://collective-docs.readthedocs.org and the developer manual at  http://plone.org/documentation/manual/developer-manual have a lot of overlap. There seems to be consensus that we should decommission the latter and merge it into the former. The collective docs could also use some editing, for grammar, accuracy, and to make sure things are organized appropriately by subject.
      > 
      > 
      > While I agree with this in principle, I think it reflects pretty poorly on a content management system that doesn't use itself for its documents (content).  I am not going to be a stickler about it, but I really think it's worth considering how this is perceived.  "Are We Not Plone?" ;-)
      
      *sigh* I am pretty passionate about this as the person whose been trying to get this fized up...
      
      Grouchy version:
      IMHO plone.org is broken beyond any sense of sanity for documentation. I have been triaging tickets, much of which includes trying to give people [explicative] permission to edit their OWN [explicative] documents and that doesn't even work. I don't know what happened to the docs on plone.org. I'm sure there are years of upgrades and insanity. To anyone who wants to encourage documentation there, I ask them to step up and fix/maintain plone.org. I know I'm not alone here. We WANT to do the right thing but...
      
      Hopeful Version:
      Maybe we start with a fresh plone and migrate any documentation worth a shit to that plone. docs,plone.org could be its own uncoupled instance and everything can be right and fresh with permissions  again. This way, we can also uncouple editing marketing crap from being able to edit docs so everyone can have more perms right off the bat.
      
      Liz
      
      > 
      > 
      >> 2. Garden the knowledgebase.
      >> a. Identify out of date articles, and either update them or move them into an "attic" folder.
      >> b. Make sure that the intended ability for regular plone.org users to edit KB articles actually works.
      >> 3. Write new documentation for things that are underdocumented. Ideas:
      >> a. Dexterity tutorial and/or manual oriented toward people working through the web (I want to work on this one. Would be great to be able to work with someone else to help me figure out an outline for what needs to be documented.)
      >> b. Manual describing Plone core development process
      >> c. Plone sysadmin guide
      >> d. plone.app.theming tutorial, including sections on how to install and tweak an existing theme, and how to create a new theme, and misc tips & tricks
      > 
      > 
      > I have an idea that I would like to implement, with input and feedback from everyone of course.  Essentially I'd like to have one page which is a jumping off point for people brand new to Plone.    I call these "QuickStarts".  You're familiar with my installation quickstart already.  I've seen it help really frustrated people get off and running in under 30 minutes.  I'd like to write two or three more and have them done and presented in a "bam bam bam, you want to do these things" format.  The others are:
      > 
      > - "So you want to make a form"
      > - Subclassing a content type
      > - Overriding a view/viewlet
      > - Rolling a Plone theme w/Diazo
      > 
      > I consider these different from "documentation" because they don't go into detail.  Consider the cooking metaphor.  You can buy a 500 page cooking book and learn all about the Maillard reaction and various types of metal used in knives and study flavor pairings, or you can follow a Cook's Illustrated recipe and have dinner. Now.  Sure, if you want to be a GOOD cook, you should learn how to break down a chicken, but often people just want to get up and running and feel a sense of accomplishment.
      > 
      > I can't write these alone because they require a consensus of current best practices and I'm pretty sure I'm not following them!  Just like last Cioppino where I asked a lot of questions and wrote it all out and had it tested, I'd like to do the same this time, but I think I can work faster and get more done.  I've actually DONE all of the things and I have good working examples that I can work from and get feedback on how to do it right.
      > 
      > I'd really like to push this kind of document up front to the user, and then we can link from within it to the "real" documentation that goes in depth and explains everything in detail.
      > 
      > I also have seen a LOT of questions around migration and upgrading, so maybe we need to have something that is very clear on the process.
      > 
      > Finally, without any animosity here... I would like a review of Martin's documentation specifically, simply because I have run across lots of things in it that didn't work or was simply steering people (me!) in the wrong direction.  Well, maybe not "wrong", but in directions that caused me pain and cross-eyed looks from others later.  I think the information is there, but it needs to be looked at to be sure A. it actually executes, B. is clear, and C. is the most straightforward way to  go about it.
      > 
      > 
      >> 4. Explore options for letting the search feature on plone.org include selected docs from readthedocs.org in the search results.
      >> a. Option 1: Spider the pages somehow, and add lightweight catalog index entries with the right title & URL
      >> b. Option 2: solr
      >> 5. Figure out what would need to happen to keep an archive of Sphinx-based documentation for each Plone version.
      >> 
      >> plone.org-related:
      >> 
      >> 1. Make sure it's running the latest version of Plone. (Alex Clark and I are planning to work on this this weekend in hopes of having a fresh plone.org ready to go for the sprint.)
      > 
      > 
      > Speaking of which: last time we had big network issues when everyone tried to get the latest Plone.org and all eggs.  How should we prepare for this time?  Network drive? Shared eggs?  Download something in advance?
      > 
      > Which also begs the question, who's bringing the hardware (wifi + router)?  I was thinking of buying a new AirPort extreme anyways...
      > 
      > 
      >> 2. Revamp PSC so that it can automatically populate itself with all packages with the Framework :: Plone classifier on PyPI.
      >> 2. Attend to website-related tickets on trac.
      >> 
      >> Other sources of ideas/tasks:
      >> 1. Jon Stahl started a google doc which overlaps with the above ideas but goes into more detail at https://docs.google.com/document/d/1OMSwK7XlWSnfw4MsQ2vc8LOvMefm6WTbBOVtn7d2t7k/edit
      >> 2. Trac tickets tagged with "cioppino": https://dev.plone.org/report/66
      >> 
      >> How does this sound to others? What are all of you hoping to work on? (It's okay if you don't know yet.)
      >> 
      >> cheers,
      >> David
      >> 
      >> 
      >> --
      >> Archive: http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331788630739
      >> To unsubscribe send an email with subject "unsubscribe" to cioppino-discussion@....  Please contact cioppino-discussion-manager@... for questions.
      >> 
      > 
      > 
      > 
      > --
      > Archive: http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331836261524
      > To unsubscribe send an email with subject "unsubscribe" to cioppino-discussion@....  Please contact cioppino-discussion-manager@... for questions.
      > 
      
      
      • Re: thoughts toward a Cioppino sprint punch list

        from spanky on Mar 15, 2012 04:24 PM
        On Mar 15, 2012, at 11:44 AM, Elizabeth Leddy wrote:
        >> 
        >> While I agree with this in principle, I think it reflects pretty poorly on a content management system that doesn't use itself for its documents (content).  I am not going to be a stickler about it, but I really think it's worth considering how this is perceived.  "Are We Not Plone?" ;-)
        > 
        > *sigh* I am pretty passionate about this as the person whose been trying to get this fized up...
        > 
        > Grouchy version:
        > IMHO plone.org is broken beyond any sense of sanity for documentation. I have been triaging tickets, much of which includes trying to give people [explicative] permission to edit their OWN [explicative] documents and that doesn't even work. I don't know what happened to the docs on plone.org. I'm sure there are years of upgrades and insanity. To anyone who wants to encourage documentation there, I ask them to step up and fix/maintain plone.org. I know I'm not alone here. We WANT to do the right thing but...
        
        
        I fully hear you, which is why I said I'm not going to be difficult about it.  I mostly just want *progress* and not to be hampered by futzing with an impedance.  IMHO, results are King here, and the same time I'm sensitive to optics.
        
        
        > Hopeful Version:
        > Maybe we start with a fresh plone and migrate any documentation worth a shit to that plone. docs,plone.org could be its own uncoupled instance and everything can be right and fresh with permissions  again. This way, we can also uncouple editing marketing crap from being able to edit docs so everyone can have more perms right off the bat.
        
        
        Let's see what Alex (Clark) and David come up with beforehand.
        
        --
        
        ~Spanky
      • Re: thoughts toward a Cioppino sprint punch list

        from jonstahl on Mar 15, 2012 02:47 PM
        On Thu, Mar 15, 2012 at 11:44 AM, Elizabeth Leddy <camembert@...> wrote:
        
        >>> Documentation-related:
        >>> 1. Gardening and consolidating the developer manual. The collective docs at http://collective-docs.readthedocs.org and the developer manual at  http://plone.org/documentation/manual/developer-manual have a lot of overlap. There seems to be consensus that we should decommission the latter and merge it into the former. The collective docs could also use some editing, for grammar, accuracy, and to make sure things are organized appropriately by subject.
        >>
        >>
        >> While I agree with this in principle, I think it reflects pretty poorly on a content management system that doesn't use itself for its documents (content).  I am not going to be a stickler about it, but I really think it's worth considering how this is perceived.  "Are We Not Plone?" ;-)
        >
        > *sigh* I am pretty passionate about this as the person whose been trying to get this fized up...
        >
        > Grouchy version:
        > IMHO plone.org is broken beyond any sense of sanity for documentation. I have been triaging tickets, much of which includes trying to give people [explicative] permission to edit their OWN [explicative] documents and that doesn't even work. I don't know what happened to the docs on plone.org. I'm sure there are years of upgrades and insanity. To anyone who wants to encourage documentation there, I ask them to step up and fix/maintain plone.org. I know I'm not alone here. We WANT to do the right thing but...
        >
        > Hopeful Version:
        > Maybe we start with a fresh plone and migrate any documentation worth a shit to that plone. docs,plone.org could be its own uncoupled instance and everything can be right and fresh with permissions  again. This way, we can also uncouple editing marketing crap from being able to edit docs so everyone can have more perms right off the bat.
        
        
        Actually, I think it's more like "years of it being passively
        ignored."  I don't think it will be that hard to fix, I just think it
        needs some focused clueful attention.  I do think it looks really bad
        for Plone if we can't use Plone to manage documentation content in
        some way.
        
        :jon
        
        • Re: thoughts toward a Cioppino sprint punch list

          from aclark on Mar 15, 2012 03:24 PM
          Hi,
          
          Cheers to everyone for their efforts, sorry I will miss this event!
          
          On Thu, Mar 15, 2012 at 2:47 PM, Jon Stahl <jonstahl@...> wrote:
          
          > On Thu, Mar 15, 2012 at 11:44 AM, Elizabeth Leddy <camembert@...>
          > wrote:
          >
          > >>> Documentation-related:
          > >>> 1. Gardening and consolidating the developer manual. The collective
          > docs at http://collective-docs.readthedocs.org and the developer manual
          > at  http://plone.org/documentation/manual/developer-manual have a lot of
          > overlap. There seems to be consensus that we should decommission the latter
          > and merge it into the former. The collective docs could also use some
          > editing, for grammar, accuracy, and to make sure things are organized
          > appropriately by subject.
          > >>
          > >>
          > >> While I agree with this in principle, I think it reflects pretty poorly
          > on a content management system that doesn't use itself for its documents
          > (content).  I am not going to be a stickler about it, but I really think
          > it's worth considering how this is perceived.  "Are We Not Plone?" ;-)
          > >
          > > *sigh* I am pretty passionate about this as the person whose been trying
          > to get this fized up...
          > >
          > > Grouchy version:
          > > IMHO plone.org is broken beyond any sense of sanity for documentation.
          > I have been triaging tickets, much of which includes trying to give people
          > [explicative] permission to edit their OWN [explicative] documents and that
          > doesn't even work. I don't know what happened to the docs on plone.org.
          > I'm sure there are years of upgrades and insanity. To anyone who wants to
          > encourage documentation there, I ask them to step up and fix/maintain
          > plone.org. I know I'm not alone here. We WANT to do the right thing but...
          > >
          > > Hopeful Version:
          > > Maybe we start with a fresh plone and migrate any documentation worth a
          > shit to that plone. docs,plone.org could be its own uncoupled instance
          > and everything can be right and fresh with permissions  again. This way, we
          > can also uncouple editing marketing crap from being able to edit docs so
          > everyone can have more perms right off the bat.
          >
          >
          > Actually, I think it's more like "years of it being passively
          > ignored."  I don't think it will be that hard to fix, I just think it
          > needs some focused clueful attention.  I do think it looks really bad
          > for Plone if we can't use Plone to manage documentation content in
          > some way.
          >
          
          
          -1. I think it looks bad to have poorly managed content, period
          (documentation or otherwise). But if the goal is to produce quality,
          consistent, detailed and constantly relevant documentation for the Plone
          project, then I don't think the tool of choice necessarily has to include
          Plone. It could, but I don't think "eat your own dogfood" is a good enough
          argument here. To put it another way: Plone is really good at public-facing
          website content, particularly the kind that only changes every so often.
          But it's not quite as good at documentation management for a large open
          source project like Plone (compared to something more lightweight and
          specific-for-the-task like Sphinx IMHO.)
          
          
          So it's "Eat your own dogfood" vs. "Use right tool for the job" where the
          latter wins IMHO because:
          
          
             - Choosing the latter requires much less overhead, and does not mean
             People will automatically think "Plone sucks" (you can easily explain the
             choice.)
             - Choosing the former costs more than it's worth, because we can't do as
             good a job as we'd like to do; and we have to work too hard to maintain the
             infrastructure for that decision.
          
          
          
          
          Alex
          
          
          
          
          
          >
          > :jon
          >
          >
          > --
          > Archive:
          > http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331837244371
          > To unsubscribe send an email with subject "unsubscribe" to
          > cioppino-discussion@....  Please contact
          > cioppino-discussion-manager@... for questions.
          >
          >
          
          
          -- 
          Alex Clark · http://pythonpackages.com
          
          
          • Re: thoughts toward a Cioppino sprint punch list

            from rossp on Mar 16, 2012 02:16 PM
            On Thu, Mar 15, 2012 at 12:24 PM, Alex Clark <aclark@...> wrote:
            > -1. I think it looks bad to have poorly managed content, period
            > (documentation or otherwise). But if the goal is to produce quality,
            > consistent, detailed and constantly relevant documentation for the Plone
            > project, then I don't think the tool of choice necessarily has to include
            > Plone. It could, but I don't think "eat your own dogfood" is a good enough
            > argument here. To put it another way: Plone is really good at public-facing
            > website content, particularly the kind that only changes every so often. But
            > it's not quite as good at documentation management for a large open source
            > project like Plone (compared to something more lightweight and
            > specific-for-the-task like Sphinx IMHO.)
            >
            > So it's "Eat your own dogfood" vs. "Use right tool for the job" where the
            > latter wins IMHO because:
            >
            > Choosing the latter requires much less overhead, and does not mean People
            > will automatically think "Plone sucks" (you can easily explain the choice.)
            > Choosing the former costs more than it's worth, because we can't do as good
            > a job as we'd like to do; and we have to work too hard to maintain the
            > infrastructure for that decision.
            
            I agree with Jon in some hypothetical world where we as a community
            make Plone, or at least the plone.org docs, close to the quality of
            external doc management systems.  But if we fail to do that, then that
            can cause much more damage to Plone's reputation than not hosting our
            own docs would.  So I think we need to evaluate what it would take to
            make docs succeed on plone.org and then be real honest with ourselves
            about the chances of that happening.
            
            Ross
            
            • Re: thoughts toward a Cioppino sprint punch list

              from fulvio on Mar 16, 2012 03:39 PM
              +1 for table
              +1 for beds/air mattresses
              
              I'm particularly interested in item #1, Gardening and consolidating the
              developer manual.
              
              I think there is value in looking at some successful examples of
              documentation in other projects.  I bet everyone can think of their own
              favorites.
              If we can start with the big picture of where we want to be, then it
              becomes easier to extricate ourselves from the brambles.
              I've had this conversation three years ago with Ross, and a few weeks ago
              in Munich with Liz.  My personal favorite is MediaWiki (for the docs), and
              here is why:
              
              
                 - The homepage has some valuable overview-type content, with useful
                 jumping-off points:  http://www.mediawiki.org/wiki/MediaWiki
                 - *Every* *single* function, global variable, class, and what-not is
                 documented in its own page, with details about which version it was
                 introduced in, usage, and cross-references to other places in the
                 documentation.  Just a couple random examples:
                    - http://www.mediawiki.org/wiki/WgGroupPermissions
                    - http://www.mediawiki.org/wiki/Manual:Hooks/APIGetAllowedParams
                    - http://www.mediawiki.org/wiki/API:Edit
                 - As is true for MediaWiki in general, every page (hence, every
                 documentation page) has a "discussion" tab, in which people can ask
                 questions and comment on inaccuracies, omissions, etc.  The "formal"
                 content is not polluted with ephemeral random comments, but it only takes
                 one click to contribute, or find additional historical information on the
                 "discussion" tab.
                 - There is no overhead to contribute.  It's all TTW.  I'm sure that's a
                 big reason for Wikipedia's success.  The only hurdle (and it does filter
                 out some people) is that you have to use wiki syntax (though I bet they
                 have better wysiwyg now).
              
              It may be a bit unfair to use MediaWiki as a poster child, after all they
              are a documentation platform, so they better have a good story for
              documenting themselves.  But I strongly feel that we should look at the
              reasons why it works so well.
              
              I know we have a bias toward Sphinx.  I think shpinx is great, and it
              produces beautiful docs.  I remember Martin talking about it in his
              presentation in Bristol, and his point is valid:  as a developer, it's
              important to have as little context switches as possible.  You write code,
              and you document in the same editor (even in the same file, in some
              cases).  I guess the question is, on whom do we want to put the burden of
              context switching overhead:  the developers or the users?
              
              That said, I don't want to suggest we give up on sphinx.
              -- 
              Fulvio
              
              
              
              
              On Fri, Mar 16, 2012 at 11:16 AM, Ross Patterson <me@...> wrote:
              
              > On Thu, Mar 15, 2012 at 12:24 PM, Alex Clark <aclark@...> wrote:
              > > -1. I think it looks bad to have poorly managed content, period
              > > (documentation or otherwise). But if the goal is to produce quality,
              > > consistent, detailed and constantly relevant documentation for the Plone
              > > project, then I don't think the tool of choice necessarily has to include
              > > Plone. It could, but I don't think "eat your own dogfood" is a good
              > enough
              > > argument here. To put it another way: Plone is really good at
              > public-facing
              > > website content, particularly the kind that only changes every so often.
              > But
              > > it's not quite as good at documentation management for a large open
              > source
              > > project like Plone (compared to something more lightweight and
              > > specific-for-the-task like Sphinx IMHO.)
              > >
              > > So it's "Eat your own dogfood" vs. "Use right tool for the job" where the
              > > latter wins IMHO because:
              > >
              > > Choosing the latter requires much less overhead, and does not mean People
              > > will automatically think "Plone sucks" (you can easily explain the
              > choice.)
              > > Choosing the former costs more than it's worth, because we can't do as
              > good
              > > a job as we'd like to do; and we have to work too hard to maintain the
              > > infrastructure for that decision.
              >
              > I agree with Jon in some hypothetical world where we as a community
              > make Plone, or at least the plone.org docs, close to the quality of
              > external doc management systems.  But if we fail to do that, then that
              > can cause much more damage to Plone's reputation than not hosting our
              > own docs would.  So I think we need to evaluate what it would take to
              > make docs succeed on plone.org and then be real honest with ourselves
              > about the chances of that happening.
              >
              > Ross
              >
              >
              > --
              > Archive:
              > http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331921794412
              > To unsubscribe send an email with subject "unsubscribe" to
              > cioppino-discussion@....  Please contact
              > cioppino-discussion-manager@... for questions.
              >
              >
              
              
        • Re: thoughts toward a Cioppino sprint punch list

          from David Glick on Mar 16, 2012 04:11 PM
          On 3/15/12 11:47 AM, Jon Stahl wrote:
          > On Thu, Mar 15, 2012 at 11:44 AM, Elizabeth Leddy<camembert@...>  wrote:
          >
          >>>> Documentation-related:
          >>>> 1. Gardening and consolidating the developer manual. The collective docs at http://collective-docs.readthedocs.org and the developer manual at  http://plone.org/documentation/manual/developer-manual have a lot of overlap. There seems to be consensus that we should decommission the latter and merge it into the former. The collective docs could also use some editing, for grammar, accuracy, and to make sure things are organized appropriately by subject.
          >>>
          >>> While I agree with this in principle, I think it reflects pretty poorly on a content management system that doesn't use itself for its documents (content).  I am not going to be a stickler about it, but I really think it's worth considering how this is perceived.  "Are We Not Plone?" ;-)
          >> *sigh* I am pretty passionate about this as the person whose been trying to get this fized up...
          >>
          >> Grouchy version:
          >> IMHO plone.org is broken beyond any sense of sanity for documentation. I have been triaging tickets, much of which includes trying to give people [explicative] permission to edit their OWN [explicative] documents and that doesn't even work. I don't know what happened to the docs on plone.org. I'm sure there are years of upgrades and insanity. To anyone who wants to encourage documentation there, I ask them to step up and fix/maintain plone.org. I know I'm not alone here. We WANT to do the right thing but...
          >>
          >> Hopeful Version:
          >> Maybe we start with a fresh plone and migrate any documentation worth a shit to that plone. docs,plone.org could be its own uncoupled instance and everything can be right and fresh with permissions  again. This way, we can also uncouple editing marketing crap from being able to edit docs so everyone can have more perms right off the bat.
          >
          > Actually, I think it's more like "years of it being passively
          > ignored."  I don't think it will be that hard to fix, I just think it
          > needs some focused clueful attention.  I do think it looks really bad
          > for Plone if we can't use Plone to manage documentation content in
          > some way.
          >
          >
          +1. I'm happy to help get to the bottom of the permission issues; can 
          you point me to the relevant tickets?
          David
          
          
          ----------		
          David Glick
           Web Developer
           davidglick@...
           206.286.1235x32
          
          The Engagement Party 2012. So much more fun than the wedding reception.
          
          http://www.npoengagementparty.com
          
          
          
          • Re: thoughts toward a Cioppino sprint punch list

            from Elizabeth Leddy on Mar 16, 2012 04:16 PM
            On Mar 16, 2012, at 1:11 PM, David Glick wrote:
            
            > On 3/15/12 11:47 AM, Jon Stahl wrote:
            >> On Thu, Mar 15, 2012 at 11:44 AM, Elizabeth Leddy<camembert@...>  wrote:
            >> 
            >>>>> Documentation-related:
            >>>>> 1. Gardening and consolidating the developer manual. The collective docs at http://collective-docs.readthedocs.org and the developer manual at  http://plone.org/documentation/manual/developer-manual have a lot of overlap. There seems to be consensus that we should decommission the latter and merge it into the former. The collective docs could also use some editing, for grammar, accuracy, and to make sure things are organized appropriately by subject.
            >>>> 
            >>>> While I agree with this in principle, I think it reflects pretty poorly on a content management system that doesn't use itself for its documents (content).  I am not going to be a stickler about it, but I really think it's worth considering how this is perceived.  "Are We Not Plone?" ;-)
            >>> *sigh* I am pretty passionate about this as the person whose been trying to get this fized up...
            >>> 
            >>> Grouchy version:
            >>> IMHO plone.org is broken beyond any sense of sanity for documentation. I have been triaging tickets, much of which includes trying to give people [explicative] permission to edit their OWN [explicative] documents and that doesn't even work. I don't know what happened to the docs on plone.org. I'm sure there are years of upgrades and insanity. To anyone who wants to encourage documentation there, I ask them to step up and fix/maintain plone.org. I know I'm not alone here. We WANT to do the right thing but...
            >>> 
            >>> Hopeful Version:
            >>> Maybe we start with a fresh plone and migrate any documentation worth a shit to that plone. docs,plone.org could be its own uncoupled instance and everything can be right and fresh with permissions  again. This way, we can also uncouple editing marketing crap from being able to edit docs so everyone can have more perms right off the bat.
            >> 
            >> Actually, I think it's more like "years of it being passively
            >> ignored."  I don't think it will be that hard to fix, I just think it
            >> needs some focused clueful attention.  I do think it looks really bad
            >> for Plone if we can't use Plone to manage documentation content in
            >> some way.
            >> 
            >> 
            > +1. I'm happy to help get to the bottom of the permission issues; can you point me to the relevant tickets?
            
            I get mostly emails but next ticket I'll send your way. Here are two I know offhand:
            1. The issues of throwing an error when accessing private content and not being logged in
            2. I have been trying to give Peter Holzer access to http://plone.org/support/user-groups/ so that he could add his user group. He can't edit anything still (even though you'll see he should have full perms)
            
            More importantly on that note, I think its not right that only a few people have access to that page (and others). Maybe we can do a general sweep and open up permissions to be more wiki like across the site?
            
            liz
            
            > David
            > 
            > 
            > ----------		
            > David Glick
            > Web Developer
            > davidglick@...
            > 206.286.1235x32
            > 
            > The Engagement Party 2012. So much more fun than the wedding reception.
            > 
            > http://www.npoengagementparty.com
            > 
            > 
            > 
            > 
            > --
            > Archive: http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331928675398
            > To unsubscribe send an email with subject "unsubscribe" to cioppino-discussion@....  Please contact cioppino-discussion-manager@... for questions.
            > 
            
            
            
    • Re: thoughts toward a Cioppino sprint punch list

      from bdbaddog on Mar 15, 2012 02:54 PM
      On Mar 15, 2012, at 11:30 AM, Tom Kapanka wrote:
      
      >> 
      > 
      > 
      > Speaking of which: last time we had big network issues when everyone tried to get the latest Plone.org and all eggs.  How should we prepare for this time?  Network drive? Shared eggs?  Download something in advance?
      > 
      > Which also begs the question, who's bringing the hardware (wifi + router)?  I was thinking of buying a new AirPort extreme anyways...
      > 
      
      I had on my list of things to bring:
      1. Long (100ft ish) eth cable
      2. wireless router (N if I have a spare)
      3. Power strips (I remember shufflying power adapters at the table)
      4. spare mice (so Ross doens't have to use his Android touch screen again.. though that was pretty cool that it worked..)
      5. a eth switch or two. (I have some 5 port'ers laying around 100mb should be good enough).
      
      Was wondering if it's possible to locally mirror pypi ?
      Do we need to bring another table? (I have a folding table, though it's a bit large and cannot bring it in my vehicle)
      
      Other items?
      
      -Bill
      
      
      
      
      • Re: thoughts toward a Cioppino sprint punch list

        from gogobd on Mar 15, 2012 03:04 PM
        Just chipping in: we are setting up a mirror pypi.akbild.ac.at just now and maybe anyone wants to test it? In about 24h from now? Gogo.
        
        
        
        On Mar 15, 2012, at 19:54, William Deegan <bill@...> wrote:
        
        > 
        > On Mar 15, 2012, at 11:30 AM, Tom Kapanka wrote:
        > 
        >>> 
        >> 
        >> 
        >> Speaking of which: last time we had big network issues when everyone tried to get the latest Plone.org and all eggs.  How should we prepare for this time?  Network drive? Shared eggs?  Download something in advance?
        >> 
        >> Which also begs the question, who's bringing the hardware (wifi + router)?  I was thinking of buying a new AirPort extreme anyways...
        >> 
        > 
        > I had on my list of things to bring:
        > 1. Long (100ft ish) eth cable
        > 2. wireless router (N if I have a spare)
        > 3. Power strips (I remember shufflying power adapters at the table)
        > 4. spare mice (so Ross doens't have to use his Android touch screen again.. though that was pretty cool that it worked..)
        > 5. a eth switch or two. (I have some 5 port'ers laying around 100mb should be good enough).
        > 
        > Was wondering if it's possible to locally mirror pypi ?
        > Do we need to bring another table? (I have a folding table, though it's a bit large and cannot bring it in my vehicle)
        > 
        > Other items?
        > 
        > -Bill
        > 
        > 
        > 
        > 
        > 
        > --
        > Archive: http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331837689683
        > To unsubscribe send an email with subject "unsubscribe" to cioppino-discussion@....  Please contact cioppino-discussion-manager@... for questions.
        > 
        
        
        • Re: thoughts toward a Cioppino sprint punch list

          from gogobd on Mar 16, 2012 08:39 AM
          FYI the academy of fine arts has set up a pypi mirror - open for every 01. Check "pypi.akbild.ac.at"; greetings, Gg
          
          
          • Re: thoughts toward a Cioppino sprint punch list

            from spanky on Mar 16, 2012 12:22 PM
            The problem is not mirroring, the problem is bandwidth.  But thanks, we'll keep it in mind if PyPi goes down.  Funny, I had lunch with the guy who runs PyPi at PyCon.  We gave him a little ribbing about it going down.
            
            --
            
            ~Spanky
            
            On Mar 16, 2012, at 5:39 AM, Bernhard Gogo wrote:
            
            > FYI the academy of fine arts has set up a pypi mirror - open for every 01. Check "pypi.akbild.ac.at"; greetings, Gg
            > 
            > 
            > 
            > --
            > Archive: http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331901547765
            > To unsubscribe send an email with subject "unsubscribe" to cioppino-discussion@....  Please contact cioppino-discussion-manager@... for questions.
            > 
            
            
            • Re: thoughts toward a Cioppino sprint punch list

              from bdbaddog on Mar 16, 2012 12:25 PM
              Gogo,
              
              How much disk space did it take to mirror Pypi?
              I might make a mirror and bring it with me to the sprint if I can..
              
              -Bill
              On Mar 16, 2012, at 9:21 AM, Tom Kapanka wrote:
              
              > The problem is not mirroring, the problem is bandwidth.  But thanks, we'll keep it in mind if PyPi goes down.  Funny, I had lunch with the guy who runs PyPi at PyCon.  We gave him a little ribbing about it going down.
              > 
              > --
              > 
              > ~Spanky
              > 
              > On Mar 16, 2012, at 5:39 AM, Bernhard Gogo wrote:
              > 
              >> FYI the academy of fine arts has set up a pypi mirror - open for every 01. Check "pypi.akbild.ac.at"; greetings, Gg
              >> 
              >> 
              >> 
              >> --
              >> Archive: http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331901547765
              >> To unsubscribe send an email with subject "unsubscribe" to cioppino-discussion@....  Please contact cioppino-discussion-manager@... for questions.
              >> 
              > 
              > 
              > 
              > --
              > Archive: http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331914923940
              > To unsubscribe send an email with subject "unsubscribe" to cioppino-discussion@....  Please contact cioppino-discussion-manager@... for questions.
              > 
              
              
              • Re: thoughts toward a Cioppino sprint punch list

                from gogobd on Mar 16, 2012 12:27 PM
                I can't tell you (i'm out of office) but on monday i can "du -sh" it :-)
                
                
                
                On Mar 16, 2012, at 17:25, William Deegan <bill@...> wrote:
                
                > Gogo,
                > 
                > How much disk space did it take to mirror Pypi?
                > I might make a mirror and bring it with me to the sprint if I can..
                > 
                > -Bill
                > On Mar 16, 2012, at 9:21 AM, Tom Kapanka wrote:
                > 
                >> The problem is not mirroring, the problem is bandwidth.  But thanks, we'll keep it in mind if PyPi goes down.  Funny, I had lunch with the guy who runs PyPi at PyCon.  We gave him a little ribbing about it going down.
                >> 
                >> --
                >> 
                >> ~Spanky
                >> 
                >> On Mar 16, 2012, at 5:39 AM, Bernhard Gogo wrote:
                >> 
                >>> FYI the academy of fine arts has set up a pypi mirror - open for every 01. Check "pypi.akbild.ac.at"; greetings, Gg
                >>> 
                >>> 
                >>> 
                >>> --
                >>> Archive: http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331901547765
                >>> To unsubscribe send an email with subject "unsubscribe" to cioppino-discussion@....  Please contact cioppino-discussion-manager@... for questions.
                >>> 
                >> 
                >> 
                >> 
                >> --
                >> Archive: http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331914923940
                >> To unsubscribe send an email with subject "unsubscribe" to cioppino-discussion@....  Please contact cioppino-discussion-manager@... for questions.
                >> 
                > 
                > 
                > 
                > --
                > Archive: http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331915119118
                > To unsubscribe send an email with subject "unsubscribe" to cioppino-discussion@....  Please contact cioppino-discussion-manager@... for questions.
                > 
                
                
                • Re: thoughts toward a Cioppino sprint punch list

                  from aclark on Mar 16, 2012 12:29 PM
                  On Fri, Mar 16, 2012 at 12:27 PM, Georg Bernhard <gogo@...>wrote:
                  
                  > I can't tell you (i'm out of office) but on monday i can "du -sh" it :-)
                  >
                  
                  
                  
                  
                  Probably about 4-5GB, according to:
                  http://www.zopyx.de/blog/creating-a-local-pypi-mirror and factoring in for
                  some growth since that was written.
                  
                  
                  
                  
                  >
                  >
                  >
                  > On Mar 16, 2012, at 17:25, William Deegan <bill@...>
                  > wrote:
                  >
                  > > Gogo,
                  > >
                  > > How much disk space did it take to mirror Pypi?
                  > > I might make a mirror and bring it with me to the sprint if I can..
                  > >
                  > > -Bill
                  > > On Mar 16, 2012, at 9:21 AM, Tom Kapanka wrote:
                  > >
                  > >> The problem is not mirroring, the problem is bandwidth.  But thanks,
                  > we'll keep it in mind if PyPi goes down.  Funny, I had lunch with the guy
                  > who runs PyPi at PyCon.  We gave him a little ribbing about it going down.
                  > >>
                  > >> --
                  > >>
                  > >> ~Spanky
                  > >>
                  > >> On Mar 16, 2012, at 5:39 AM, Bernhard Gogo wrote:
                  > >>
                  > >>> FYI the academy of fine arts has set up a pypi mirror - open for every
                  > 01. Check "pypi.akbild.ac.at"; greetings, Gg
                  > >>>
                  > >>>
                  > >>>
                  > >>> --
                  > >>> Archive:
                  > http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331901547765
                  > >>> To unsubscribe send an email with subject "unsubscribe" to
                  > cioppino-discussion@....  Please contact
                  > cioppino-discussion-manager@... for questions.
                  > >>>
                  > >>
                  > >>
                  > >>
                  > >> --
                  > >> Archive:
                  > http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331914923940
                  > >> To unsubscribe send an email with subject "unsubscribe" to
                  > cioppino-discussion@....  Please contact
                  > cioppino-discussion-manager@... for questions.
                  > >>
                  > >
                  > >
                  > >
                  > > --
                  > > Archive:
                  > http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331915119118
                  > > To unsubscribe send an email with subject "unsubscribe" to
                  > cioppino-discussion@....  Please contact
                  > cioppino-discussion-manager@... for questions.
                  > >
                  >
                  >
                  >
                  > --
                  > Archive:
                  > http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331915256337
                  > To unsubscribe send an email with subject "unsubscribe" to
                  > cioppino-discussion@....  Please contact
                  > cioppino-discussion-manager@... for questions.
                  >
                  >
                  
                  
                  -- 
                  Alex Clark · http://pythonpackages.com
                  
                  
        • Re: thoughts toward a Cioppino sprint punch list

          from Elizabeth Leddy on Mar 15, 2012 03:17 PM
          sure!
          
          Bill - I think a table would be a good idea but I don't have room either and I think we can get by with sitting on the couch.
          
          Should we bring a blow up bed or two again?
          
          liz
          
          Elizabeth Leddy
          camembert@...
          @eleddy
          
          On Mar 15, 2012, at 12:04 PM, Georg Bernhard wrote:
          
          > Just chipping in: we are setting up a mirror pypi.akbild.ac.at just now and maybe anyone wants to test it? In about 24h from now? Gogo.
          > 
          > 
          > 
          > On Mar 15, 2012, at 19:54, William Deegan <bill@...> wrote:
          > 
          >> 
          >> On Mar 15, 2012, at 11:30 AM, Tom Kapanka wrote:
          >> 
          >>>> 
          >>> 
          >>> 
          >>> Speaking of which: last time we had big network issues when everyone tried to get the latest Plone.org and all eggs.  How should we prepare for this time?  Network drive? Shared eggs?  Download something in advance?
          >>> 
          >>> Which also begs the question, who's bringing the hardware (wifi + router)?  I was thinking of buying a new AirPort extreme anyways...
          >>> 
          >> 
          >> I had on my list of things to bring:
          >> 1. Long (100ft ish) eth cable
          >> 2. wireless router (N if I have a spare)
          >> 3. Power strips (I remember shufflying power adapters at the table)
          >> 4. spare mice (so Ross doens't have to use his Android touch screen again.. though that was pretty cool that it worked..)
          >> 5. a eth switch or two. (I have some 5 port'ers laying around 100mb should be good enough).
          >> 
          >> Was wondering if it's possible to locally mirror pypi ?
          >> Do we need to bring another table? (I have a folding table, though it's a bit large and cannot bring it in my vehicle)
          >> 
          >> Other items?
          >> 
          >> -Bill
          >> 
          >> 
          >> 
          >> 
          >> 
          >> --
          >> Archive: http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331837689683
          >> To unsubscribe send an email with subject "unsubscribe" to cioppino-discussion@....  Please contact cioppino-discussion-manager@... for questions.
          >> 
          > 
          > 
          > 
          > --
          > Archive: http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331838273845
          > To unsubscribe send an email with subject "unsubscribe" to cioppino-discussion@....  Please contact cioppino-discussion-manager@... for questions.
          > 
          
          
          
          • Re: thoughts toward a Cioppino sprint punch list

            from bdbaddog on Mar 15, 2012 03:23 PM
            Liz,
            
            Beds +1 
            
            -Bill
            On Mar 15, 2012, at 12:17 PM, Elizabeth Leddy wrote:
            
            > sure!
            > 
            > Bill - I think a table would be a good idea but I don't have room either and I think we can get by with sitting on the couch.
            > 
            > Should we bring a blow up bed or two again?
            > 
            > liz
            > 
            > Elizabeth Leddy
            > camembert@...
            > @eleddy
            > 
            > On Mar 15, 2012, at 12:04 PM, Georg Bernhard wrote:
            > 
            >> Just chipping in: we are setting up a mirror pypi.akbild.ac.at just now and maybe anyone wants to test it? In about 24h from now? Gogo.
            >> 
            >> 
            >> 
            >> On Mar 15, 2012, at 19:54, William Deegan <bill@...> wrote:
            >> 
            >>> 
            >>> On Mar 15, 2012, at 11:30 AM, Tom Kapanka wrote:
            >>> 
            >>>>> 
            >>>> 
            >>>> 
            >>>> Speaking of which: last time we had big network issues when everyone tried to get the latest Plone.org and all eggs.  How should we prepare for this time?  Network drive? Shared eggs?  Download something in advance?
            >>>> 
            >>>> Which also begs the question, who's bringing the hardware (wifi + router)?  I was thinking of buying a new AirPort extreme anyways...
            >>>> 
            >>> 
            >>> I had on my list of things to bring:
            >>> 1. Long (100ft ish) eth cable
            >>> 2. wireless router (N if I have a spare)
            >>> 3. Power strips (I remember shufflying power adapters at the table)
            >>> 4. spare mice (so Ross doens't have to use his Android touch screen again.. though that was pretty cool that it worked..)
            >>> 5. a eth switch or two. (I have some 5 port'ers laying around 100mb should be good enough).
            >>> 
            >>> Was wondering if it's possible to locally mirror pypi ?
            >>> Do we need to bring another table? (I have a folding table, though it's a bit large and cannot bring it in my vehicle)
            >>> 
            >>> Other items?
            >>> 
            >>> -Bill
            >>> 
            >>> 
            >>> 
            >>> 
            >>> 
            >>> --
            >>> Archive: http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331837689683
            >>> To unsubscribe send an email with subject "unsubscribe" to cioppino-discussion@....  Please contact cioppino-discussion-manager@... for questions.
            >>> 
            >> 
            >> 
            >> 
            >> --
            >> Archive: http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331838273845
            >> To unsubscribe send an email with subject "unsubscribe" to cioppino-discussion@....  Please contact cioppino-discussion-manager@... for questions.
            >> 
            > 
            > 
            > 
            > --
            > Archive: http://www.coactivate.org/[…]/1331839045862
            > To unsubscribe send an email with subject "unsubscribe" to cioppino-discussion@.... Please contact cioppino-discussion-manager@... for questions.
            
            
            
      • Re: thoughts toward a Cioppino sprint punch list

        from spanky on Mar 15, 2012 04:21 PM
        On Mar 15, 2012, at 11:54 AM, William Deegan wrote:
        
        > 
        > On Mar 15, 2012, at 11:30 AM, Tom Kapanka wrote:
        > 
        >>> 
        >> 
        >> 
        >> Speaking of which: last time we had big network issues when everyone tried to get the latest Plone.org and all eggs.  How should we prepare for this time?  Network drive? Shared eggs?  Download something in advance?
        >> 
        >> Which also begs the question, who's bringing the hardware (wifi + router)?  I was thinking of buying a new AirPort extreme anyways...
        >> 
        > 
        > I had on my list of things to bring:
        > 1. Long (100ft ish) eth cable
        > 2. wireless router (N if I have a spare)
        
        I will be brining my AirportExtreme (N). Bring yours too, backups are essential.
        
        > 3. Power strips (I remember shufflying power adapters at the table)
        
        
        I have BOXES of them from PloneConf.
        
        
        > 4. spare mice (so Ross doens't have to use his Android touch screen again.. though that was pretty cool that it worked..)
        > 5. a eth switch or two. (I have some 5 port'ers laying around 100mb should be good enough).
        > 
        > Was wondering if it's possible to locally mirror pypi ?
        > Do we need to bring another table? (I have a folding table, though it's a bit large and cannot bring it in my vehicle)
        
        
        I was thinking about this.  I understand that people, when working, want to sit at a table rather than use their laps.  It just isn't very feasible to sit on a couch and code for hours, so I understand why everyone gravitates to the kitchen (biggest table).  But I'd like to engineer a "Sprint Space" that isn't crammed into a kitchen area.  So a table (and chairs) would probably be pretty helpful.  I'll revisit the photos of the place and see if there are any clues as to what's already there.
        
        I don't want to tear up the kitchen (move tables OUT) to accomplish this, so if it has to be the kitchen again, so be it, but I was going to make an effort to have it not be the case.
        
        
        > Other items?
        > 
        > -Bill
        > 
        > 
        > 
        > 
        > 
        > --
        > Archive: http://www.coactivate.org/projects/cioppino/lists/cioppino-discussion/archive/2012/03/1331837689683
        > To unsubscribe send an email with subject "unsubscribe" to cioppino-discussion@....  Please contact cioppino-discussion-manager@... for questions.
        > 
        
        
      • Re: thoughts toward a Cioppino sprint punch list

        from David Glick on Mar 16, 2012 04:09 PM
        On 3/15/12 11:54 AM, William Deegan wrote:
        > Other items?
        >
        Anyone have a whiteboard and/or flipchart with markers? I seem to 
        remember someone bringing these last year...
        David
        
        
        ----------		
        David Glick
         Web Developer
         davidglick@...
         206.286.1235x32
        
        The Engagement Party 2012. So much more fun than the wedding reception.
        
        http://www.npoengagementparty.com
        
        
        
        • Re: thoughts toward a Cioppino sprint punch list

          from stevem on Mar 16, 2012 08:10 PM
          On Fri, Mar 16, 2012 at 1:09 PM, David Glick <davidglick@...>wrote:
          
          > On 3/15/12 11:54 AM, William Deegan wrote:
          >
          >> Other items?
          >>
          >>  Anyone have a whiteboard and/or flipchart with markers? I seem to
          > remember someone bringing these last year...
          >
          
          I do. I did. I will again.
          
          
      • Re: thoughts toward a Cioppino sprint punch list

        from David Glick on Mar 16, 2012 04:09 PM
        On 3/15/12 11:54 AM, William Deegan wrote:
        > Other items?
        >
        Anyone have a whiteboard and/or flipchart with markers? I seem to 
        remember someone bringing these last year...
        David
        
        
        ----------		
        David Glick
         Web Developer
         davidglick@...
         206.286.1235x32
        
        The Engagement Party 2012. So much more fun than the wedding reception.
        
        http://www.npoengagementparty.com
        
        
        
        • Re: thoughts toward a Cioppino sprint punch list

          from bdbaddog on Mar 16, 2012 04:40 PM
          I have some large paper post it boards
          
          
          
          
          On Mar 16, 2012, at 12:57 PM, David Glick <davidglick@...> wrote:
          
          > On 3/15/12 11:54 AM, William Deegan wrote:
          >> Other items?
          >> 
          > Anyone have a whiteboard and/or flipchart with markers? I seem to remember someone bringing these last year...
          > David
          > 
          > 
          > ----------        
          > David Glick
          > Web Developer
          > davidglick@...
          > 206.286.1235x32
          > 
          > The Engagement Party 2012. So much more fun than the wedding reception.
          > 
          > http://www.npoengagementparty.com
          > 
          >