From mint-bounce@lists.fishpool.fi Sat May 29 08:22:31 2010 Message-ID: <4C01067D.8000402@atari-source.org> Date: Sat, 29 May 2010 08:20:13 -0400 From: Mark Duckworth User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Wratt , mint Subject: Re: [MiNT] MiNTLib / Kernel Future and also SpareMiNT..... References: <4BFEBEFB.9000304@atari-source.org> <1274987559.11662.17.camel@jetpack.demon.co.uk> <4BFEDB32.9070705@online.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: mduckworth@atari-source.org Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: On 5/29/10 3:02 AM, Paul Wratt wrote: > this was the an issue I have brought up in the past. > > using the bugtracker is fine, but the biggest problem is you have to be: > A) a user on the system > B) have to have certain rights to use extended project management (like roadmap) > > I believe it to be ok for the bugtracker to contain a general outline > for the roadmap. > > But I also believe that the roadmap should be Wiki style, ie you dont > need to be a developer with admin privilages to add or edit it > > As for Jo's comment about "attracting more coders"& "get to know the > code base", these need to be tied in with source documentation > > If the roadmap were to be wiki style, other people who are not > currently developers (because of time or commitments), can add details > at the technical level. > > This would also allow for a "loose knit" project group to be formed, > maintained and managed, without the need to place commitment on any > one person (or key people) > > Overall though, it seems to me that all current developers need to > update there current documentation, websites, and web apps etc.. > > That would be the first step is clearly seeing an over direction that > the community is taking, and allow others (especially by current > developers) to see specific direction of key items or ideas currently > being worked on > > what ever what future development is organised, it should be as > totally open as possible, without the need for access rights, etc, > that people can come and go as they need to. > > Should the unthinkable happen (which it has all ready), there will be > no hold-ups it continuing momentum, whether those are dev work, or > documentation, or project detailing, or testing, or non-coding dev > work Myself and probably many others still disagree that it shouldn't just be completely and utterly open like that. Open and democratic doesn't have to mean constantly fixing random damage caused by an inexperienced or misguided user. Same with cvs/svn, same with everything else. Thanks, Mark