Re: [Zope-dev] Fishbowl not problem centered enough
- Original Message - From: Chris Withers [EMAIL PROTECTED] To: Jay, Dylan [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, June 20, 2001 10:32 PM Subject: Re: [Zope-dev] Fishbowl not problem centered enough I just see lots of solutions many of which attack some of the same problems and no clear way to get those people comunicating and making informed trade-offs I think this is a really good point. However, I think the fishbowl should remain the center for solutions. The collector is the center for problems. I kind of see bugs and problems as two different things. Problems are things that Zope doesn't do or doesn't do easily, bugs are faults that stop things working as advertised. Collector is centainly the place for bugs but fishbowl is certainly the place for the reasons people need extensions to zope. What I see as missing is a mapping between problems and solutions. I'd love to see what bugs or issues a proposal addresses and I'd like to be able to 'vote' for proposals on that basis. Do other people think this would be a good idea? If so, what would need to be done for it to become a reality? I don't think its a hard thing to do. You give each problem a wiki page. You might have to use [blah blah blah] style links if the names get too wordy. You implement a system for placing a vote on a problem page. Every registered user gets just 5 votes. I have some code for this lying around somewhere (uses sql however) Then you have one big page listing all the problems in order of votes. (DC might get more votes maybe). Then each solution gets its own wiki page too. Each solution has a link to the problems it solves. Backlinks from the problem lead to all the possible solutions. Maybe there is scope for voting on the solutions too? Its still the same fishbowl. I'm just suggesting a slight reorganization. since there are too many people trying to solve the same problems without knowing or caring. cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Fishbowl not problem centered enough
I just see lots of solutions many of which attack some of the same problems and no clear way to get those people comunicating and making informed trade-offs I think this is a really good point. However, I think the fishbowl should remain the center for solutions. The collector is the center for problems. What I see as missing is a mapping between problems and solutions. I'd love to see what bugs or issues a proposal addresses and I'd like to be able to 'vote' for proposals on that basis. Do other people think this would be a good idea? If so, what would need to be done for it to become a reality? cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Fishbowl not problem centered enough
I think it would be helpful to have a big picture, with goals and objectives, into which to fit the pieces - would that address the kinds of things you're talking about? big picture is good but its not what I mean. What I mean is a list like this... snip These are all good ideas. There is quite a lot going on at the moment, but I do want to get these issues addressed. The next big step (in progress) is opening up CVS. After that I'd like to start taking care of some of the fishbowl issues. It would be really great if someone could capture some of the issues and ideas in this thread in a meta-proposal to ensure that they stay on the radar. Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.371.6909 Digital Creations http://www.digicool.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Fishbowl not problem centered enough
Jay, Dylan wrote: Fishbowl is a great idea but it seems to be that its solution focused rather than problem focus. Perhaps if you had a page that listed all the problems with zope or problems that need to be solved that isn't as easy as it could be with zope. The fishbowl is also pull technology, and so it is time-consuming to keep up with the developments. I personally find it to be cumbersome, limiting and not really conducive to actually getting stuff done. The collector currently fulfills the role of a bug list, and to some degree a feature request bin. However, I (and others) find using it for the latter is often a waste of time. Problems could then be organized according to priority due to severity or strategy, or even voting via the comunity (ala Java bug parade developer.java.sun.com/developer/bugParade/) Then under each problem could be listed the proposals that form solutions to the problem. Of course some solutions may solve many problems and therefore appear more than once. I agree that a community-centered bug/feature request collector would be beneficial. One that does not rely exclusively on DC's resources. DC just does not have the bandwidth to deal with everyone's needs. I know there has been talk of opening up the Zope CVS to outside contributions, I personally think this is long overdue. In order for a community development forum to really work, this would have to happen. I just see lots of solutions many of which attack some of the same problems and no clear way to get those people comunicating and making informed trade-offs This is one of the challenges of open-source development. I think we as a community need to leverage our own technology more to facilitate its further development. And I think that means relying on DC less and therefore decentralizing things more. I know that the folks at DC are thinking seriously about these issues. I would say that unless something is actually done soon about opening the Zope core to outside contributors, they run the serious risk of someone just forking the code to do it for them. I also think that Zope.org itself could greatly benefit from direct outside contribution. Dylan Jay mailto:[EMAIL PROTECTED] Avaya Communication Tel: +61 2 9886-8961 Level 3, 123 Epping RoadFAX: +61 2 9352 9224 Nth Ryde NSW 2113 Mobile: 0409 606 171 AUSTRALIA -- | Casey Duncan | Kaivo, Inc. | [EMAIL PROTECTED] `-- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Fishbowl not problem centered enough
On Wed, 20 Jun 2001 09:24:40 -0600, Casey Duncan [EMAIL PROTECTED] wrote: Jay, Dylan wrote: Fishbowl is a great idea but it seems to be that its solution focused rather than problem focus. Perhaps if you had a page that listed all the problems with zope or problems that need to be solved that isn't as easy as it could be with zope. I think it would be helpful to have a big picture, with goals and objectives, into which to fit the pieces - would that address the kinds of things you're talking about? The fishbowl is also pull technology, and so it is time-consuming to keep up with the developments. I personally find it to be cumbersome, limiting and not really conducive to actually getting stuff done. I've really wanted to enable people to subscribe to notification about changes to wiki pages, and to notifications about additions to the wiki. Unfortunately, i didn't have time to get to that in the WikiForNow project. As soon as i'm clear form a current project i *may* be able to concentrate on at least formulating a reasonable quick-and-dirty way to do notifications, and getting it done for the short term. Whether or not it's me doing it, i think we're going to be bringing more attention to these issues. I know there has been talk of opening up the Zope CVS to outside contributions, I personally think this is long overdue. In order for a community development forum to really work, this would have to happen. This actually is high in our priorities, but the key players have been swamped. From a discussion w/paul recently i think we'll be getting some more attention to doing this, very soon. I just see lots of solutions many of which attack some of the same problems and no clear way to get those people comunicating and making informed trade-offs I think the fishbowl, as it is, is a good significant move towards exposing the process and enabling involvement. Mailling lists help conduct the collaboration. However, more is needed to facilitate that process - selectively enabling checkins, doing notifications to make tracking of developments manageable, fleshing out the context (problems/big picture). It's an incremental process, and we may have lapsed too long in progressing on those increments - perhaps we need to chart out some of these critical pieces, so we can better formulate how they're being attacked - and maybe enable more help with the increments. I hope to have expore this some, internally, and have more to say about it next week. Ken Manheimer [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Fishbowl not problem centered enough
Ken Manheimer wrote: On Wed, 20 Jun 2001 09:24:40 -0600, Casey Duncan [EMAIL PROTECTED] wrote: Jay, Dylan wrote: Fishbowl is a great idea but it seems to be that its solution focused rather than problem focus. Perhaps if you had a page that listed all the problems with zope or problems that need to be solved that isn't as easy as it could be with zope. I think it would be helpful to have a big picture, with goals and objectives, into which to fit the pieces - would that address the kinds of things you're talking about? The fishbowl is also pull technology, and so it is time-consuming to keep up with the developments. I personally find it to be cumbersome, limiting and not really conducive to actually getting stuff done. I've really wanted to enable people to subscribe to notification about changes to wiki pages, and to notifications about additions to the wiki. Unfortunately, i didn't have time to get to that in the WikiForNow project. As soon as i'm clear form a current project i *may* be able to concentrate on at least formulating a reasonable quick-and-dirty way to do notifications, and getting it done for the short term. Whether or not it's me doing it, i think we're going to be bringing more attention to these issues. Opening the development process itself could enhance the resources available to you and solve this problem. However, I have more issues with wikis than just the notification aspect. I think they limit accessibility of data because they are really just big globs of text. I personally feel the whole fishbowl concept has some flaws both in technical and administrative implementation. I for one don't exactly know how to proceed beyond a certain point in the fishbowl. Some of my proposals for example end with some thing like this from DC: I think we need to address this a different way, however I don't have time to say exactly how right now. OK, so now what? I know there has been talk of opening up the Zope CVS to outside contributions, I personally think this is long overdue. In order for a community development forum to really work, this would have to happen. This actually is high in our priorities, but the key players have been swamped. From a discussion w/paul recently i think we'll be getting some more attention to doing this, very soon. I understand, but this is the way to get some more resources on your side in the long run. I for one will shed an entire frustration level with Zope when this happens. I think the fishbowl, as it is, is a good significant move towards exposing the process and enabling involvement. Mailling lists help conduct the collaboration. However, more is needed to facilitate that process - selectively enabling checkins, doing notifications to make tracking of developments manageable, fleshing out the context (problems/big picture). It's an incremental process, and we may have lapsed too long in progressing on those increments - perhaps we need to chart out some of these critical pieces, so we can better formulate how they're being attacked - and maybe enable more help with the increments. I agree that the fishbowl is beneficial, if for nothing else than a sounding board for the possible directions of Zope. But, like I mentioned before, I think the community needs more involvement directly with the development of its own tools like the fishbowl. I realize there is a risk to DC of loosing some level of direct control, but I suggest that a democratic development approach although less decisive and centralized is superior to a despotism. I hope to have expore this some, internally, and have more to say about it next week. I'll await further developments. -- | Casey Duncan | Kaivo, Inc. | [EMAIL PROTECTED] `-- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Fishbowl not problem centered enough
-Original Message-
From: Ken Manheimer [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 21 June 2001 2:53 AM
To: [EMAIL PROTECTED]
Cc: Casey Duncan; Jay, Dylan; Paul Everitt; Jim Fulton
Subject: Re: [Zope-dev] Fishbowl not problem centered enough
On Wed, 20 Jun 2001 09:24:40 -0600, Casey Duncan [EMAIL PROTECTED]
wrote:
Jay, Dylan wrote:
Fishbowl is a great idea but it seems to be that its
solution focused rather
than problem focus. Perhaps if you had a page that listed
all the problems
with zope or problems that need to be solved that isn't
as easy as it could
be with zope.
I think it would be helpful to have a big picture, with goals and
objectives, into which to fit the pieces - would that address
the kinds of
things you're talking about?
big picture is good but its not what I mean.
What I mean is a list like this
--
ZODB is not fault tolerent
- ZODBReplication
No way to use Zope with source control
- DirectoryStorage - ZODB
- CVSStorage
- ZODBFileSystemSynchronization
Need clearer seperation between presentation and code
- HiperDOM
etc etc
-
What I'm suggesting is turning the focus on its head. If every day your
looking at problems rather than proposed solutions it promotes the following
- Ideas about alternative solutions
- Focused debate about tradeoffs between alternatives
- a clear way to determine priority of proposed solutions by determining
priority of the problems they solve. People can vote on the problems to
gauge the need in the community. This is something that you guys need. eg No
one at work will take zope seriously if they can't use source control to
intergrate into our existing processes. If I'm alone then thats cool, but if
lots of people are in the same boat but arn't about mailing the dev list to
tell everyone then you'll never know and lose all those potential zopisters.
Voting could be done by giving each problem a page with a special tag.
Every user gets 5 votes to place on any page with the tag. When ever the
problem changes status then everyone who voted gets notified. When the
problem is solved all those votes get refunded. If someones priorities
change then they just move their votes around. (The java bug parage was an
inspired idea IMHO)
The fishbowl is also pull technology, and so it is
time-consuming to
keep up with the developments. I personally find it to be
cumbersome,
limiting and not really conducive to actually getting stuff done.
I've really wanted to enable people to subscribe to notification about
changes to wiki pages, and to notifications about additions
to the wiki.
Unfortunately, i didn't have time to get to that in the WikiForNow
project. As soon as i'm clear form a current project i *may*
be able to
concentrate on at least formulating a reasonable
quick-and-dirty way to do
notifications, and getting it done for the short term. Whether or not
it's me doing it, i think we're going to be bringing more attention to
these issues.
I wrote a quick and dirty one for this. I'll include the code at the bottom
of the email.
However someone recently suggested something better. The idea that you can
send email to a wiki page. To take this futher imagine if every wikipage is
a mailing list. Everyone who adds to it becomes a subscriber or you can
subscribe manually to become a lurker. Then every update gets mailed to
everyone. Then every reply becomes a comment at the end of the page. Perhaps
every wikipage created from the original page inherits its subscribers. Of
course you can unsubscribe at any time (have to be real easy to do like one
click at bottom of email). Email addresses would be something like
[EMAIL PROTECTED] or something.
So what problem does this solve?
- Lack of awareness of wiki changes
- Email discussion is easier than wiki discussion but essentially the same
thing however they get recorded in different places with no connection
between each other
- No more good idea, but record it on the wiki comments
Anyway the code I wrote (just for stright subscription) went like this. It
relies on an XML document to keep the subscribers but that can be replaced
by some kind of map. It also relies of ZCron to do the checks every 5min or
so. If you guys added a flexible change notification hook (Listener talker
pattern) it would make like much easier. eg The idea of subcribing to events
on any object like change and add events.
add_subscriber(self, user, page_name)
doc = self.subscribers
body = doc.getElementsByTagName('subscriptions')[0]
n = doc.createElement('Notify')
body.appendChild(n)
p = doc.createElement('Page')
p.appendChild(doc.createTextNode(page_name))
n.appendChild(p)
u = doc.createElement('User')
u.appendChild(doc.createTextNode(user))
n.appendChild(u)
remove_sbscriber(self, user, page_name)
doc = self.subscribers.getElementsByTagName('subscriptions')[0]
sub = []
for e
RE: [Zope-dev] Fishbowl not problem centered enough
-Original Message- From: Casey Duncan [mailto:[EMAIL PROTECTED]] Sent: Thursday, 21 June 2001 3:30 AM To: Ken Manheimer Cc: [EMAIL PROTECTED]; Jay, Dylan; Paul Everitt; Jim Fulton Subject: Re: [Zope-dev] Fishbowl not problem centered enough I agree that the fishbowl is beneficial, if for nothing else than a sounding board for the possible directions of Zope. But, like I mentioned before, I think the community needs more involvement directly with the development of its own tools like the fishbowl. I realize there is a risk to DC of loosing some level of direct control, but I suggest that a democratic development approach although less decisive and centralized is superior to a despotism. I'm not so sure about this idea. Benevolent dictators are always going to be 10 times more efficient than democracy. I just think we need to improve the consultitive process and have some focus on what is really trying to be achieved. I aggree that the changes to Zope have been way to slow but then again Zope is going in 5 directions at once which is not a good idea esp if none of those ways work togeather. Perhaps more transparency of the DC's strategies for where zope is going would be good. Also transparency of the criteria by which we should be evaluating new proposals. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
