Re: [Sycamore-Dev] Sycamore development planning
I setup http://www.projectsycamore.org/Bugs and http:// www.projectsycamore.org/Feature_Requests as described below. I tried to make it flexible for the user by pointing to trac and mentioning that they can also use the wiki. We should emphasize using the wiki as the report mechanism for users of Sycamore that don't wish to get involved in the development process. AD On May 22, 2007, at 4:32 PM, [EMAIL PROTECTED] wrote: Using the Project Sycamore wiki as the user interface to the project is a good idea. I don't think normal user should have to deal with TRAC to report issues. Ya, you're right. I tried. :) For bugs: JaneUser submits bug report at ProjectSycamore.org/Bugs An active developer examines the report and creates a ticket in TRAC if its determined to actually be a bug (not a feature or a mis- configuration of the software). The bug report is removed or archived at ProjectSycamore.org/Known_Bugs. We'll have to work to keep track of what sycamore version, affected wikis, etc. For example bug x affects rocwiki but not daviswiki. For Feature Requests: JaneUser submits a request at ProjectSycamore.org/Feature_Requests The development community examines the requests, and if its a feature to explore, a Wiki page is created to facilitate discussion. ProjectSycamore.org/Feature_Requests/Do_XYZ Once the development community has determine to implement a request, it is entered into TRAC and assigned to the appropriate milestone. Sounds good to me. ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev
Re: [Sycamore-Dev] Sycamore development planning
are there not corresponding pages on wikispot.org, perhaps redirects should be made? On 5/23/07, Adam Dewitz [EMAIL PROTECTED] wrote: I setup http://www.projectsycamore.org/Bugs and http:// www.projectsycamore.org/Feature_Requests as described below. I tried to make it flexible for the user by pointing to trac and mentioning that they can also use the wiki. We should emphasize using the wiki as the report mechanism for users of Sycamore that don't wish to get involved in the development process. AD On May 22, 2007, at 4:32 PM, [EMAIL PROTECTED] wrote: Using the Project Sycamore wiki as the user interface to the project is a good idea. I don't think normal user should have to deal with TRAC to report issues. Ya, you're right. I tried. :) For bugs: JaneUser submits bug report at ProjectSycamore.org/Bugs An active developer examines the report and creates a ticket in TRAC if its determined to actually be a bug (not a feature or a mis- configuration of the software). The bug report is removed or archived at ProjectSycamore.org/Known_Bugs. We'll have to work to keep track of what sycamore version, affected wikis, etc. For example bug x affects rocwiki but not daviswiki. For Feature Requests: JaneUser submits a request at ProjectSycamore.org/Feature_Requests The development community examines the requests, and if its a feature to explore, a Wiki page is created to facilitate discussion. ProjectSycamore.org/Feature_Requests/Do_XYZ Once the development community has determine to implement a request, it is entered into TRAC and assigned to the appropriate milestone. Sounds good to me. ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev
Re: [Sycamore-Dev] Sycamore development planning
There are a number of wikis that use Sycamore not on Wiki Spot. None of these are running the same 'version' of Sycamore as Wiki Spot (yet). This requires two separate bug reports and feature requests. On May 23, 2007, at 9:34 PM, David Poole wrote: are there not corresponding pages on wikispot.org, perhaps redirects should be made? ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev
Re: [Sycamore-Dev] Sycamore development planning
Uhm, okay, just thought I would ask, as it would have seemed logical to thusly have a page for each version on the sycamore.wikispot.org site that had the feedback and changelog, and perhaps source, etc. available, thusly making the effort well organized by the wiki. Thusly the wikis could have bug reports direct to the version of the wiki software that they correspond to. Do I make sense? is this a good idea perhaps? I mean I like the mailing list, but it would be nice to have more accessible and open information. On 5/23/07, Adam Dewitz [EMAIL PROTECTED] wrote: There are a number of wikis that use Sycamore not on Wiki Spot. None of these are running the same 'version' of Sycamore as Wiki Spot (yet). This requires two separate bug reports and feature requests. On May 23, 2007, at 9:34 PM, David Poole wrote: are there not corresponding pages on wikispot.org, perhaps redirects should be made? ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev
Re: [Sycamore-Dev] Sycamore development planning
It's a good question. But I think the duplication is necessary for the time being. Trac provides the component and milestone level detail required to keep all this organized on the development level. I don't forsee Sycamore changing drastically that separate end user documentation needs to exist for each release. AD On May 23, 2007, at 10:21 PM, David Poole wrote: Uhm, okay, just thought I would ask, as it would have seemed logical to thusly have a page for each version on the sycamore.wikispot.org site that had the feedback and changelog, and perhaps source, etc. available, thusly making the effort well organized by the wiki. Thusly the wikis could have bug reports direct to the version of the wiki software that they correspond to. Do I make sense? is this a good idea perhaps? I mean I like the mailing list, but it would be nice to have more accessible and open information. On 5/23/07, Adam Dewitz [EMAIL PROTECTED] wrote: There are a number of wikis that use Sycamore not on Wiki Spot. None of these are running the same 'version' of Sycamore as Wiki Spot (yet). This requires two separate bug reports and feature requests. On May 23, 2007, at 9:34 PM, David Poole wrote: are there not corresponding pages on wikispot.org, perhaps redirects should be made? ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev
Re: [Sycamore-Dev] Sycamore development planning
It would be nice for a changelog though, also for the css but that is totally a wikispot thing. On 5/23/07, Adam Dewitz [EMAIL PROTECTED] wrote: It's a good question. But I think the duplication is necessary for the time being. Trac provides the component and milestone level detail required to keep all this organized on the development level. I don't forsee Sycamore changing drastically that separate end user documentation needs to exist for each release. AD On May 23, 2007, at 10:21 PM, David Poole wrote: Uhm, okay, just thought I would ask, as it would have seemed logical to thusly have a page for each version on the sycamore.wikispot.org site that had the feedback and changelog, and perhaps source, etc. available, thusly making the effort well organized by the wiki. Thusly the wikis could have bug reports direct to the version of the wiki software that they correspond to. Do I make sense? is this a good idea perhaps? I mean I like the mailing list, but it would be nice to have more accessible and open information. On 5/23/07, Adam Dewitz [EMAIL PROTECTED] wrote: There are a number of wikis that use Sycamore not on Wiki Spot. None of these are running the same 'version' of Sycamore as Wiki Spot (yet). This requires two separate bug reports and feature requests. On May 23, 2007, at 9:34 PM, David Poole wrote: are there not corresponding pages on wikispot.org, perhaps redirects should be made? ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev
Re: [Sycamore-Dev] Sycamore development planning
For sure. We could probably do something like http:// www.projectsycamore.org/Releases/.1 and so on. Each release would have a page documenting release notes, the change log, upgrade instructions, etc. On May 23, 2007, at 11:11 PM, David Poole ([EMAIL PROTECTED]) wrote: It would be nice for a changelog though, also for the css but that is totally a wikispot thing. ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev
Re: [Sycamore-Dev] Sycamore development planning
We need to have a person-oriented place where those who are not coding can see what we're working on. The projectsycamore.org wiki serves that function well (or could). For instance, this page is a good example of something that everyone who's actively maintaining a wiki would be interested in from a high-level perspective: http://www.projectsycamore.org/Semantic_Wiki. Projectsycamore.org is the familiar and convenient environment for active wiki / wiki spot folks. I could go either way. The trac wiki is just as usable as the sycamore wiki (or any other wiki) for this kind of data. Philip makes a good point about being person-oriented. We need to make it easy for jane and joe to notify us of a problem. Posting a note to a Bugs wiki page helps by making it easy to do and a familiar interface. Using sycamore to manage bugs about sycamore has the advantage because bug reporters don't have to learn a new wiki language. As far as having everything in one place... If that's a goal then we should force users to report bugs into trac directly. That would save a lot of developer's time but would be more cumbersome for bug reporters because they'd have to learn a new interface. So, my opinion is that we have the sycamore wiki for design docs/discussion (mainly because it's familiar and I don't want to taint my wiki knowledge by using multiple wikis), the trac wiki just point to the sycamore wiki (as it does now), and have users report bugs directly into the trac ticket tracker (I'm notoriously lazy). All discussion about a particular *bug* should be in the comments of the ticket (not on the mailing list). For *features* that require design changes, database changes, etc these should be made into a wiki page and a ticket should be added for that feature. There should be a link to the ticket in the wiki and to the wiki in the ticket. The discussion for large features could happen in the wiki or on the mailing list but it should be stored on the wiki for posterity. Comments? Scott ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev
Re: [Sycamore-Dev] Sycamore development planning
So, my opinion is that we have the sycamore wiki for design docs/discussion (mainly because it's familiar and I don't want to taint my wiki knowledge by using multiple wikis), the trac wiki just point to the sycamore wiki (as it does now), and have users report bugs directly into the trac ticket tracker (I'm notoriously lazy). All discussion about a particular *bug* should be in the comments of the ticket (not on the mailing list). For *features* that require design changes, database changes, etc these should be made into a wiki page and a ticket should be added for that feature. There should be a link to the ticket in the wiki and to the wiki in the ticket. The discussion for large features could happen in the wiki or on the mailing list but it should be stored on the wiki for posterity. I don't think wiki end-users will go through the hoops needed to put a ticket into devjavu. At rocwiki, we have a Bug Report page and then we move the bugs into trac. In general, the lower the barrier for entry, the more likely you're going to get a bug report. The rest of this is fine with me. I don't see real integration between trac's ticket system and the wiki, so links would be needed no matter what. Storing everything for posterity is critical. ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev
Re: [Sycamore-Dev] Sycamore development planning
Issues like this are exactly why a layer between end user bug reporting and trac ticket creation should exist. A little bit of triage will need to be applied to a report before it gets acted on. This need will grow as more people adopt sycamore as their wiki of choice. AD On May 22, 2007, at 4:32 PM, [EMAIL PROTECTED] wrote: For bugs: JaneUser submits bug report at ProjectSycamore.org/Bugs An active developer examines the report and creates a ticket in TRAC if its determined to actually be a bug (not a feature or a mis- configuration of the software). The bug report is removed or archived at ProjectSycamore.org/Known_Bugs. We'll have to work to keep track of what sycamore version, affected wikis, etc. For example bug x affects rocwiki but not daviswiki. ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev
Re: [Sycamore-Dev] Sycamore development planning
On managing developers -- that's kinda what I mean. Me and everyone else involved is volunteering time, so being told what to do doesn't make any sense (that's what I think of when I think of managing). Perhaps my use of the word overzealous was overzealous. Letting people know what you're working on or what you're interested in working on is a good idea and I definitely agree with what RC said. --Philip On 5/21/07, Far McKon [EMAIL PROTECTED] wrote: Good idea, but let's not be too overzealous with this side of stuff. This may be a tough topic to talk about, because I think your 'overzealous' is somewhere in other people 'normal project needs' range. And perhaps Adam's 'minimum work' is somewhere in someone else's overzealous range. IMHO, communication has been a bit poor at times, since different folks have different expectations. This project is slowly accumulating some contributors, and since Phillip is keen on coding, not on managing developers, I think we should find a way to offload that onto someone who would be interested in that end of things. Naturally, Scott comes to mind. He seems good at organizing, documenting, etc. If Scott is interested, does anyone object to making him the informal developer community organizer? -Far On 5/21/07, Philip Neustrom [EMAIL PROTECTED] wrote: Good idea, but let's not be too overzealous with this side of stuff. --philip On 5/20/07, Adam Dewitz [EMAIL PROTECTED] wrote: Regarding http://www.projectsycamore.org/Sapling/Roadmap Philip asked: Can we keep features in their own branches so they can be rejected or accepted more appropriately? In the past we've had monolithic branches, like wikis, etc, but I think we should shy away from that as much as possible as time goes on. (Meaning we just move these over to the Sycamore version roadmap page, rather than have versions for the unstable trunk [sapling]? I think this is a good time to discuss the future of Sycamore roadmaps, release schedules, and all the other project management tasks associated with (open source) software development. AD ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev
Re: [Sycamore-Dev] Sycamore development planning
On 5/21/07, Scott Beardsley [EMAIL PROTECTED] wrote: Rottenchester wrote: Does anyone think the following process is overzealous? not me. 1. Developers and users come to broad agreement on the goals of the next few months' worth of releases. Examples: bug fix release, new mapping and comment feature release etc. 2. Upon agreement, the release is numbered and placed in trac as a milestones. 3. Features are entered as enhancement tickets in trac, targeted to the release. 4. Bugs are entered as defect tickets in trac. Normally, each bug would be targeted to the next release. 5. Developers take tickets, check in code against those tickets, and mark the ticket closed. This seems like a bare minimum process. Yup, all pretty standard stuff. I've revised you process a bit. Let me know what you think... 1. Identify a problem or feature 2. Add/modify the bug/feature report in trac 3. Propose a solution 4. Discussion, documentation, add/modify expected milestone 5. Jump to 1 until a refined solution and consensus emerges 6. Implement the solution and mark item as fixed Obviously, it doesn't address the more complex issues of how we're going to merge trunk/wikis/sapling and what each branch is supposed to do. I think feature-based or milestone-based branches might work well. It is looking more and more like sapling is the latest and greatest. It makes sense to move it to the trunk once it stabilizes. Also, I'd like to add a releases directory for tarballs of each release. Someone (I'll volunteer if nobody else wants to do it) would build a tarball and upload it to SVN which makes it available via trac. This would allow non developers to download and install stable Sycamore releases (I remember seeing a comment from a user about this somewhere). Tarballs would rock. We also should look into the python distutils stuff [though, it's unclear to me how much of an advantage it provides]. IMHO, communication has been a bit poor at times, since different folks have different expectations. This project is slowly accumulating some contributors, and since Phillip is keen on coding, not on managing developers, I think we should find a way to offload that onto someone who would be interested in that end of things. Naturally, Scott comes to mind. He seems good at organizing, documenting, etc. If Scott is interested, does anyone object to making him the informal developer community organizer? I appreciate the vote of confidence. I am certainly interested in helping organize, but at this point having a repo-nazi might cause problems. I've seen projects fail because one person drops the ball and I don't want to be that person. Sycamore is naturally community-oriented, let's try to keep things community oriented in the development side as well. IMO most problems can be solved through a combination of discussion and examples. If ya'll really want me to do something specific we can talk about those things as they come up. The goal is to make the process efficient and inviting without getting bogged down in endless discussion. This presentation[1] about poisonous people in OS might help illustrate my points. If we find a need it might help to schedule meetings on IRC. I try to go in there when I'm working on Sycamore stuff, but it's usually pretty empty. Good point on IRC. I'll personally start hanging out in #sycamore (freenode) to stave off the emptiness. --Philip Scott [1] http://video.google.com/videoplay?docid=-4216011961522818645 ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev
Re: [Sycamore-Dev] Sycamore development planning
Yup, all pretty standard stuff. I've revised you process a bit. Let me know what you think... 1. Identify a problem or feature 2. Add/modify the bug/feature report in trac 3. Propose a solution 4. Discussion, documentation, add/modify expected milestone 5. Jump to 1 until a refined solution and consensus emerges 6. Implement the solution and mark item as fixed This sounds good - I'm still learning about trac. Is there a way to integrate the discussion with the ticket so that all the information about a particular feature is captured? Perhaps a wiki page for the ticket? ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev
Re: [Sycamore-Dev] Sycamore development planning
Philip Neustrom wrote: Tarballs would rock. We also should look into the python distutils stuff [though, it's unclear to me how much of an advantage it provides]. Yes, I agree. Being able to build an egg would be nice. Let's stick with just tarballs of the source for now. ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev
Re: [Sycamore-Dev] Sycamore development planning
On managing developers -- that's kinda what I mean. Me and everyone else involved is volunteering time, so being told what to do doesn't make any sense (that's what I think of when I think of managing). Oh? When I think of managing, I think of the stuff like e-mailing folks to ask what they are working on, helping people come to agreement on 'bug fix release' or 'new feature release' type stuff. IE, letting developers develop, and just helping them keep on the same page. With terms like 'repo nazi' thrown around, I think we are using the term 'managing' in totally different ways. For better software, we should be working as a team, and somebody should be doing things like grabbing everyone into a chat every month or two, checking out of the branches are duplicating work, etc. Seeing if we have sane docs so new folks can use things. Asking folks if they can change priorities to match a goal, or suggest new work for folks that want to help, but don't know where to start. Not hard to do stuff, nor time consuming, but that's project management. To be frank, it's been hard getting answers, documentation, or details from you Phillip. I think (based on pretty limited interaction) it might make life easier on you if you don't feel stressed to respond to each of those e-mails, or get tied up in that stuff. - Far Perhaps my use of the word overzealous was overzealous. Letting people know what you're working on or what you're interested in working on is a good idea and I definitely agree with what RC said. --Philip On 5/21/07, Far McKon [EMAIL PROTECTED] wrote: Good idea, but let's not be too overzealous with this side of stuff. This may be a tough topic to talk about, because I think your 'overzealous' is somewhere in other people 'normal project needs' range. And perhaps Adam's 'minimum work' is somewhere in someone else's overzealous range. IMHO, communication has been a bit poor at times, since different folks have different expectations. This project is slowly accumulating some contributors, and since Phillip is keen on coding, not on managing developers, I think we should find a way to offload that onto someone who would be interested in that end of things. Naturally, Scott comes to mind. He seems good at organizing, documenting, etc. If Scott is interested, does anyone object to making him the informal developer community organizer? -Far On 5/21/07, Philip Neustrom [EMAIL PROTECTED] wrote: Good idea, but let's not be too overzealous with this side of stuff. --philip On 5/20/07, Adam Dewitz [EMAIL PROTECTED] wrote: Regarding http://www.projectsycamore.org/Sapling/Roadmap Philip asked: Can we keep features in their own branches so they can be rejected or accepted more appropriately? In the past we've had monolithic branches, like wikis, etc, but I think we should shy away from that as much as possible as time goes on. (Meaning we just move these over to the Sycamore version roadmap page, rather than have versions for the unstable trunk [sapling]? I think this is a good time to discuss the future of Sycamore roadmaps, release schedules, and all the other project management tasks associated with (open source) software development. AD ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev
Re: [Sycamore-Dev] Sycamore development planning
There are a number of reasons we having been doing all of our Roadmap development specifically targeted at the Sapling branch. The direction of Sycamore has not been communicated and project goals have not been articulated. There has never been a clear roadmap. This leads to confusion among new developers as to where the project is going. The only glimpse into your project goals is this: Wikis/Farm support this is a big one. It's essentially reworking the code to operate effectively with multiple wikis running in the same Sycamore instance. There are lots of little details pertaining to how the individual wikis work together. [1] This does not provide any insight into what this means for sites not running multiple wikis. Do all wikis need the functionality that comes with the new Wikis/Farm branch? Or is it overkill? If it's overkill, is there a need for two different versions of Sycamore: A wiki farm version and a single wiki version. I would rather spend my time building a kick ass wiki that can be easily extended by the end user to meet their specific application needs, than develop to the needs of one application (like Wiki Spot or RocWiki). Until a clear direction is outlined for trunk and wikis branch, I don't think any of the Sapling stuff should be moved over to the Sycamore version roadmap page. AD [1] http://www.projectsycamore.org/Roadmap On May 20, 2007, at 11:15 PM, Adam Dewitz wrote: Regarding http://www.projectsycamore.org/Sapling/Roadmap Philip asked: Can we keep features in their own branches so they can be rejected or accepted more appropriately? In the past we've had monolithic branches, like wikis, etc, but I think we should shy away from that as much as possible as time goes on. (Meaning we just move these over to the Sycamore version roadmap page, rather than have versions for the unstable trunk [sapling]? I think this is a good time to discuss the future of Sycamore roadmaps, release schedules, and all the other project management tasks associated with (open source) software development. AD ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev
Re: [Sycamore-Dev] Sycamore development planning
I know we have an awesome wiki to use for discussion at ProjectSycamore.org, but perhaps we should start using the TRAC Wiki to facilitate communication among developers. This keeps all the development stuff in one place. We can use the ProjectSycamore.org for general project information and documentation. Thoughts? AD On May 21, 2007, at 1:36 PM, Rottenchester wrote: This sounds good - I'm still learning about trac. Is there a way to integrate the discussion with the ticket so that all the information about a particular feature is captured? Perhaps a wiki page for the ticket? ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev
Re: [Sycamore-Dev] Sycamore development planning
I haven't gotten involved with development yet, but I'd like to eventually that said, I agree that Trac is the best place for development info and projectsycamore.org should be more of a marketing tool. I also agree that as the project grows, it's imperative that all the changes are committed to svn in a timely manner - I'd be discouraged if I had time to start hacking today and couldn't check out the most recent code. Thanks everyone for making this possible. Rottenchester wrote: Though I appreciate the idea that a project should eat its own dogfood, I think having all the development info for sycamore in trac makes good sense, because having it in one place makes it easier for new contributors to get a full picture of the project. On 5/21/07, Adam Dewitz [EMAIL PROTECTED] wrote: I know we have an awesome wiki to use for discussion at ProjectSycamore.org, but perhaps we should start using the TRAC Wiki to facilitate communication among developers. This keeps all the development stuff in one place. We can use the ProjectSycamore.org for general project information and documentation. Thoughts? AD On May 21, 2007, at 1:36 PM, Rottenchester wrote: This sounds good - I'm still learning about trac. Is there a way to integrate the discussion with the ticket so that all the information about a particular feature is captured? Perhaps a wiki page for the ticket? ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev -- Charles McLaughlin Department of Sociology University of California, Davis ___ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev
