Plone › Documentation Team

Re: If core code is undocumented it's broken (Was: where should developer documentation go?)

76 messages

1 2 3 4

vedaw () Re: If core code is undocumented it's broken (Was:where should developer documentation go?)

Reply Threaded

In reply to this post by Ricardo Newbery-2

Hi All,

Martin, Alexander Limi, SteveM and I are all taking a look at the
discussions that have been happening here and we're going to figure out the
answers here. By that, I mean that we will identify who is qualified to make
the decisions here -- editors, docs community, or perhaps a benevolent
dictator or a combination of the above. The institution of editors is still
a new thing for us, and identifying who is qualified to determine the way
forward is a tough one.

Based on that, we'll begin see some decisions fall out of these discussions.
We do hear what everyone is saying, and we plan on weighing these ideas
fairly, though likely in a room together (very soon, in fact) instead of on
the docs list.

Please just be patient, and don't feel like there isn't movement here or
that your voices aren't being heard, because they are.

- Veda

On 11/21/08 9:59 PM, "Ricardo Newbery" <[hidden email]> wrote:

>
> I truly hate harping on this but I keep hearing folks conflating
> issues...
>
> wiki != open-editing
>
> open-editing != mega-docs
>
> There are several distinctly different questions here:
>
> 1) Do we want open-editing at all?
>
> 2) If we want open-editing, do we want it in a
> separate sandbox or for all plone.org docs?
>
> 3) If we want open-editing, do we want it to be
> wiki-type or regular plone content-types?
>
> 4) Do we want mega-docs? Should they be open-edited?
> Wiki-type or regular plone content-type?
>
> Hopefully, this helps to parse out the pro and con arguments.
>
> Ric
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Plone-docs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-docs

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

Israel Saeta Pérez () Re: If core code is undocumented it's broken(Was:where should developer documentation go?)

Reply Threaded

In reply to this post by Russ Ferriday

On Sat, Nov 22, 2008 at 10:06 PM, Russ Ferriday wrote:
> I've been lurking on this list for ages, and it's time to step up...

Welcome!

> On 22 Nov 2008, at 04:31, Dylan Jay wrote:
>
> Is it possible to ask who in this whole debate actually works at the code
> level with Plone?

I consider myself a developer too. :-)

> [...]
>
> So, last week, publishing the result on plone-users was about the best/only
> thing I could manage under the circumstances. In the past 3 months I have
> had maybe 5 similar tips/snippets at my fingers that could have been useful
> to others, but did not merit an article or how-to. They probably did not
> merit the time of an editor, and also may have had short expected lifetimes.
> Sadly, these have all fallen by the wayside. This leads to the kind of
> personal frustration that Mikko expresses, because I also **depend** on such
> snippets of knowledge to get my work done. Most people in this discussion
> likewise.
> I don't have the solution to meet these needs, but I'm definitely in favour
> of a mechanism for publishing quick recipes/tips/solutions, in an informal
> way.

Snippets of code are a different type of documentation from what we
have currently at plone.org. I agree with you - they're really helpful
for developers. But I would be very scared if I were a newcomer,
browsed to plone.org/documentation and found something like that
http://code.activestate.com/recipes/langs/python/

Even if you're an intermediate developer, you often need more
comprehensive documentation than quick recipes/tips/solutions,
specially reference documentation. See, for example, the Zope
Developer's Guide or The Zope Book.

So I think our best bet to satisfy all needs would be keeping the
current documentation model/process for (hoped) up-to-date manuals,
references and most-common howtos, and create an open-editing web
space to collect quick informal recipes.

Would everybody be happy with such a solution? I hope so.

-- israel
PS. Anyways, from what Veda says (below), it looks like some
benevolent dictators will make a decision soon.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

Israel Saeta Pérez

Russ Ferriday () Re: If core code is undocumented it's broken(Was:where should developer documentation go?)

Reply Threaded

Some javascript/style in this post has been disabled (why?)

On 22 Nov 2008, at 22:04, Israel Saeta Pérez wrote:

So I think our best bet to satisfy all needs would be keeping the
current documentation model/process for (hoped) up-to-date manuals,
references and most-common howtos, and create an open-editing web
space to collect quick informal recipes.

Would everybody be happy with such a solution? I hope so.

Russ Ferriday - Topia Systems - Open Source content management with Plone and Zope
[hidden email] - office: +44 2076 1777588 - mobile: +44 7789 338868 - skype: ferriday

Dylan Jay-4 () Re: If core code is undocumented it's broken(Was:whereshould developer documentation go?)

Reply Threaded

In reply to this post by Israel Saeta Pérez

> -----Original Message-----
> From: Israel Saeta Pérez [mailto:[hidden email]]
> Sent: Sunday, 23 November 2008 9:05 AM
> So I think our best bet to satisfy all needs would be keeping the
> current documentation model/process for (hoped) up-to-date manuals,
> references and most-common howtos, and create an open-editing web
> space to collect quick informal recipes.

+1

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

Shane Graber () Re: If core code is undocumented it's broken(Was:where should developer documentation go?)

Reply Threaded

In reply to this post by Russ Ferriday

Django has something *very* similar:

http://www.djangosnippets.org/

Nothing fancy and it's easy to throw a code snippet out there for
others to use. I find that site is very usable and easy to contribute
to or to comment on someone's snippet.

I was bummed when Plone removed the wiki from their website as it was
really a nice way to throw some quick information onto a page for
others to use.

Shane

On Sat, Nov 22, 2008 at 6:38 PM, Russ Ferriday <[hidden email]> wrote:

>
> On 22 Nov 2008, at 22:04, Israel Saeta Pérez wrote:
>
> So I think our best bet to satisfy all needs would be keeping the
> current documentation model/process for (hoped) up-to-date manuals,
> references and most-common howtos, and create an open-editing web
> space to collect quick informal recipes.
>
> Would everybody be happy with such a solution? I hope so.
>
> +1
>
> Russ Ferriday - Topia Systems - Open Source content management with Plone and Zope
> [hidden email] - office: +44 2076 1777588 - mobile: +44 7789 338868 - skype: ferriday
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Plone-docs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-docs
>

--
Shane ∞ http://liquid.homelinux.org
---------
I'm so cool I can be used to prove Bose-Einstein Condensation!
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

Dylan Jay-4 () Re: If core code is undocumented it's broken(Was:whereshould developer documentation go?)

Reply Threaded

> -----Original Message-----
> From: Shane Graber [mailto:[hidden email]]
> Sent: Sunday, 23 November 2008 3:24 PM
> To: Russ Ferriday; Israel Saeta Pérez; Plone Docs List
> Subject: Re: [Plone-docs] If core code is undocumented it's
> broken(Was:whereshould developer documentation go?)
>
> Django has something *very* similar:
>
> http://www.djangosnippets.org/
>
> Nothing fancy and it's easy to throw a code snippet out there for
> others to use. I find that site is very usable and easy to contribute
> to or to comment on someone's snippet.

The snippets idea is great. I much more like the idea of open editing areas
which have a very specific objective like this than just a free for all
wiki.
What the snippets don't cover and what an official developers manual
wouldn't cover either, is shootouts between current practices. Think best
practices that change over time.

A great example is recent discussion on the product developers list on best
practices for portal_tools replacements. Someone brought up the point that
local utilities weren't current best practice anymore because they have
problems with breaking things when they are uninstalled. This kind of
information is too valuable not to try and capture in our documentation area
somehow as it saves newbies (and oldbies) a lot of time and frustration
chasing deadends that others have already discovered.

Developer section = Snippets + shootouts + official manual ??

> I was bummed when Plone removed the wiki from their website as it was
> really a nice way to throw some quick information onto a page for
> others to use.
>
> Shane
>
>
> On Sat, Nov 22, 2008 at 6:38 PM, Russ Ferriday <[hidden email]> wrote:
> >
> > On 22 Nov 2008, at 22:04, Israel Saeta Pérez wrote:
> >
> > So I think our best bet to satisfy all needs would be keeping the
> > current documentation model/process for (hoped) up-to-date manuals,
> > references and most-common howtos, and create an open-editing web
> > space to collect quick informal recipes.
> >
> > Would everybody be happy with such a solution? I hope so.
> >
> > +1
> >
> > Russ Ferriday - Topia Systems - Open Source content management with
> Plone and Zope
> > [hidden email] - office: +44 2076 1777588 - mobile: +44 7789 338868 -
> skype: ferriday
> >
> > ------------------------------------------------------------------------
> -
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > Plone-docs mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/plone-docs
> >
>
>
>
> --
> Shane 8 http://liquid.homelinux.org
> ---------
> I'm so cool I can be used to prove Bose-Einstein Condensation!
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Plone-docs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-docs

Carsten Senger-3 () Re: If core code is undocumented it's broken(Was:where should developer documentation go?)

Reply Threaded

In reply to this post by Israel Saeta Pérez

Israel Saeta Pérez schrieb:
> On Sat, Nov 22, 2008 at 10:06 PM, Russ Ferriday wrote:
>> I've been lurking on this list for ages, and it's time to step up...
>
> Welcome!
>
>> On 22 Nov 2008, at 04:31, Dylan Jay wrote:
>>
>> Is it possible to ask who in this whole debate actually works at the code
>> level with Plone?

I do.

> Snippets of code are a different type of documentation from what we
> have currently at plone.org.

Howtos are not far away (even if the currents organization of phc isn't
suited for masses of them) and Mikko collected receipts here:
http://plone.org/documentation/tutorial/manipulating-plone-objects-programmatically

> I agree with you - they're really helpful
> for developers. But I would be very scared if I were a newcomer,
> browsed to plone.org/documentation and found something like that
> http://code.activestate.com/recipes/langs/python/
>
> Even if you're an intermediate developer, you often need more
> comprehensive documentation than quick recipes/tips/solutions,
> specially reference documentation. See, for example, the Zope
> Developer's Guide or The Zope Book.
>
> So I think our best bet to satisfy all needs would be keeping the
> current documentation model/process for (hoped) up-to-date manuals,
> references and most-common howtos, and create an open-editing web
> space to collect quick informal recipes.

I like the idea of "official" documentation and lesser controlled
documentation in an open-editing space. That's what happens in Drupal
now, someone posted a link to their docteam-list some days ago.

Receipts and other documentation should at least contain a "Works for
Plone x.y" annotation. Even if almost all new receipts target plone 3.1,
this open-edit space would have to be maintained. If we had hundreds of
unsorted receipts now ranging from Plone 2.0 to 3.1 it would be insane.

Good dokumentation can be moved into the right place in the "official"
part. Bad documentation should be removed.

> Would everybody be happy with such a solution? I hope so.

I would be if we have the capacities to maintain this in the long run.
We could end up with plenty of docs that are incomplete, missleading,
outdated or plain wrong. If we can control that receips are really
helpful. If we can't, we have a good chance to discourage new
developers. I tried many code snippets in the first month I used Plone
that really frustrated me.

..Carsten

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

Russ Ferriday () Re: If core code is undocumented it's broken(Was:where should developer documentation go?)

Reply Threaded

Some javascript/style in this post has been disabled (why?)

On 23 Nov 2008, at 10:22, Carsten Senger wrote:

I would be if we have the capacities to maintain this in the long run.
We could end up with plenty of docs that are incomplete, missleading,
outdated or plain wrong. If we can control that receips are really
helpful. If we can't, we have a good chance to discourage new
developers. I tried many code snippets in the first month I used Plone
that really frustrated me.

Good comments.

If you could have quickly helped extend, moderate, clarify, or retire those snippets, you would have saved the next person. This is another barrier that would be removed in a more open space.

There is a lot of positive energy in the community that more rigid systems can easily defeat.

Mikko is just the very small tip of a very large iceberg.

--r.

Russ Ferriday - Topia Systems - Open Source content management with Plone and Zope
[hidden email] - office: +44 2076 1777588 - mobile: +44 7789 338868 - skype: ferriday

Israel Saeta Pérez () Re: If core code is undocumented it's broken(Was:where should developer documentation go?)

Reply Threaded

In reply to this post by Carsten Senger-3

On Sun, Nov 23, 2008 at 11:22 AM, Carsten Senger wrote:
> Israel Saeta wrote:
>> Would everybody be happy with such a solution? I hope so.
>
> I would be if we have the capacities to maintain this in the long run. We
> could end up with plenty of docs that are incomplete, missleading, outdated
> or plain wrong. If we can control that receips are really helpful. If we
> can't, we have a good chance to discourage new developers. I tried many code
> snippets in the first month I used Plone that really frustrated me.

No. This open-editing area was proposed mainly to bypass the review
and QA steps. We can't ask for a place to put (possibly) incomplete
and not reviewed documentation and want it to be mantained to remove
the incomplete and misleading docs.

The only maintenance you could expect is users correcting, expanding,
and flagging existing articles as outdated or wrong openly.

-- israel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

Israel Saeta Pérez

Simon Michael () pining for the wikis ?

Reply Threaded

In reply to this post by Shane Graber

Hi all.. it's good to see doc processes and technologies in the
limelight again.

Shane Graber wrote:
> I was bummed when Plone removed the wiki from their website as it was
> really a nice way to throw some quick information onto a page for
> others to use.

Not to worry, there's plenty of idle Zope wikis still waiting for users.
Carve out a space on http://wiki.zope.org/zope2 or http://wiki.zope.org
. (But plan for the future. Perhaps delete two obsolete pages for each
one you add. Sort of like planting a tree..)

Cheers - Simon

> This site went live in 2004 with the following "mission statement".
>
> We have zope.org and others; why should you spend your valuable time using and contributing to yet another zope docs site, you might ask ? And why a Zwiki-based site ?
>
> #1: more docs, less cruft
> This site is focused on one thing: efficient zope documentation. We want to be productive with zope and to spread this know-how to others. We have a clear set of policies to that end.
>
> #2: easy to update
> Don't ask, don't log in, just do it. ExternalEditor is always available.
>
> #3: the urls
> They're mnemonic. They're fuzzy . They fit in your brain.
>
> #4: it's simple
> Don't waste time thinking about non-essentials.
>
> #5: it's agile
> A good wiki is fast to use, has a fluid structure and can organize a large amount of information very quickly.
>
> #6: it's good glue
> The site works well as roadmap, outline, shared bookmarks, content repository, generic rated dtml-scriptable database, etc..
>
> #7: it's maintained
> All content can be updated at any time, and there is at least one experienced wiki gardener on duty.. or at least not too far away. The site is hosted on the actively maintained zwiki.org server and runs simple and standard software.
>
> #8: existing sites can't fill this role, yet
> zope.org ? Maybe some day. This is the next best url.
>
> #9: you can always move your content later
> Feel free to use this as a drafting-place for your GFDL doc.

JoAnna Springsteen () Re: If core code is undocumented it's broken(Was:where should developer documentation go?)

Reply Threaded

In reply to this post by Russ Ferriday

jebus Russ. sure you didn't forget anything there? ;-)

+1 to the idea of a cookbook. That's something I could see a "wiki"
being useful for. I'm hesitant to separate out the dev manuals and put
them in there as well. But if we're just talking about snippets and
recipes and quick tricks, then I'd buy into that.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

treed-2 () Re: If core code is undocumented it's broken(Was:where should developer documentation go?)

Reply Threaded

On Mon, Nov 24, 2008 at 09:08:09AM -0600, JoAnna Springsteen spake thusly:
> +1 to the idea of a cookbook. That's something I could see a "wiki"
> being useful for. I'm hesitant to separate out the dev manuals and put
> them in there as well. But if we're just talking about snippets and
> recipes and quick tricks, then I'd buy into that.

Since Plone is all about custom content types to manage content how
about a custom content type with a link on each document that a user
can click to flag the document as "out of date". Or perhaps taking
advantage of workflow to give each document a state such as "This
document works for plone version 2.5" or 3.1 or whatever. Or perhaps
it could have two attributes which can be set independently so that we
can say it works from 2.5.0 to 2.5.4 etc. I'm just wondering if we
can't use the tools we have at hand more effectively.

If Plone itself can't handle the content management needs of its own
project it is hard to make a case that it can handle the needs of my
company.

--
Tracy Reed
It's the cobbler's children who go without shoes.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

attachment0 (196 bytes) Download Attachment

Dylan Jay-4 () Re: If core code is undocumented it's broken(Was:whereshould developer documentation go?)

Reply Threaded

> -----Original Message-----
> From: Tracy Reed [mailto:[hidden email]]
> Sent: Wednesday, 26 November 2008 1:09 PM
> To: JoAnna Springsteen
> Cc: Russ Ferriday; [hidden email]
> Subject: Re: [Plone-docs] If core code is undocumented it's
> broken(Was:whereshould developer documentation go?)
>
> On Mon, Nov 24, 2008 at 09:08:09AM -0600, JoAnna Springsteen spake thusly:
> > +1 to the idea of a cookbook. That's something I could see a "wiki"
> > being useful for. I'm hesitant to separate out the dev manuals and put
> > them in there as well. But if we're just talking about snippets and
> > recipes and quick tricks, then I'd buy into that.
>
> Since Plone is all about custom content types to manage content how
> about a custom content type with a link on each document that a user
> can click to flag the document as "out of date". Or perhaps taking
> advantage of workflow to give each document a state such as "This
> document works for plone version 2.5" or 3.1 or whatever. Or perhaps
> it could have two attributes which can be set independently so that we
> can say it works from 2.5.0 to 2.5.4 etc. I'm just wondering if we
> can't use the tools we have at hand more effectively.
>
> If Plone itself can't handle the content management needs of its own
> project it is hard to make a case that it can handle the needs of my
> company.

Yes and no. Plone is a very flexible system and we can make it fit the
workflow we want... but it takes time and money. We just need to think of
the easiest ways to get to where we want to go. In particular it seems like
waiting for Plone 3.0 on Plone.org has been detrimental as its held up a lot
of changes. Thinking what we can do without changing content types might be
more expedient.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

JoAnna Springsteen () Re: If core code is undocumented it's broken(Was:where should developer documentation go?)

Reply Threaded

In reply to this post by treed-2

> Since Plone is all about custom content types to manage content how
> about a custom content type with a link on each document that a user
> can click to flag the document as "out of date".

I think we have it. We mark it as obsolete and poof it's gone from
public view. You can see obsolete ones if you have doc team rights.

Or perhaps taking
> advantage of workflow to give each document a state such as "This
> document works for plone version 2.5" or 3.1 or whatever.

Right now we have keywords that we use. But not all authors mark them.
we've gone back to try and tag as many as we can.

Or perhaps
> it could have two attributes which can be set independently so that we
> can say it works from 2.5.0 to 2.5.4 etc. I'm just wondering if we
> can't use the tools we have at hand more effectively.
> If Plone itself can't handle the content management needs of its own
> project it is hard to make a case that it can handle the needs of my
> company.

Amen. You're after my own heart here. I firmly believe we can use what
we have, tweak it a bit and make things a whole lot better.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

treed-2 () Re: If core code is undocumented it's broken(Was:whereshould developer documentation go?)

Reply Threaded

In reply to this post by Dylan Jay-4

On Wed, Nov 26, 2008 at 01:57:57PM +1100, Dylan Jay spake thusly:
> Yes and no. Plone is a very flexible system and we can make it fit the
> workflow we want... but it takes time and money. We just need to think of
> the easiest ways to get to where we want to go. In particular it seems like
> waiting for Plone 3.0 on Plone.org has been detrimental as its held up a lot
> of changes. Thinking what we can do without changing content types might be
> more expedient.

Er...but...I've always heard how fast and easy it is to whip up new
content types with Plone! It only takes a few minutes with a GUI tool
to create a new content type: I saw Sean Kelly's screencast! ;)

What, you mean I've been sold a bill of goods?

--
Tracy Reed
http://tracyreed.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

attachment0 (196 bytes) Download Attachment

Dylan Jay-4 () Re: If core code is undocumented it'sbroken(Was:whereshould developer documentation go?)

Reply Threaded

> -----Original Message-----
> From: Tracy Reed [mailto:[hidden email]]
> Sent: Wednesday, 26 November 2008 2:45 PM
> To: Dylan Jay
> Cc: [hidden email]
> Subject: Re: [Plone-docs] If core code is undocumented
> it'sbroken(Was:whereshould developer documentation go?)
>
> On Wed, Nov 26, 2008 at 01:57:57PM +1100, Dylan Jay spake thusly:
> > Yes and no. Plone is a very flexible system and we can make it fit the
> > workflow we want... but it takes time and money. We just need to think
> of
> > the easiest ways to get to where we want to go. In particular it seems
> like
> > waiting for Plone 3.0 on Plone.org has been detrimental as its held up a
> lot
> > of changes. Thinking what we can do without changing content types might
> be
> > more expedient.
>
> Er...but...I've always heard how fast and easy it is to whip up new
> content types with Plone! It only takes a few minutes with a GUI tool
> to create a new content type: I saw Sean Kelly's screencast! ;)
>
> What, you mean I've been sold a bill of goods?

Haha. Well there is more to new features than just coding. There is BA,
migration, testing and deployment. Plus all the change management issues of
dealing with people used to an old UI. So whatever we do isn't something you
want to redo that often.
I think most of the options are out on the table now and I trust the editor
team to make a good decision on direction that we can all contribute to.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

1 2 3 4