On 8/23/07, Dan Chokola <[EMAIL PROTECTED]> wrote: > On 8/23/07, Sham Chukoury <[EMAIL PROTECTED]> wrote: > > On 23/08/2007, at 10:38PM, Sébastien Cevey wrote: > > > > > I think that separating dev and user websites is a good idea. Most > > > other projects do it that way, and it seems to work fine. > > > > I agree. I used to be of the opinion that having a user-oriented > > site, as well as a developer oriented site, would result in too much > > maintenance work. Having now largely taken a break from XMMS2 for a > > while, I can see that it makes sense to have this different > > branding.. Besides, the content on the wiki didn't seem to change all > > that much while I've been inactive on it, so it looks like it won't > > be much extra work maintaining 2 sub sites (essentially). In the end, > > it makes sense to have a certain distinction between users and > > developers, because they're different audiences. XMMS2 being an open > > source project, there is a degree of overlap between the two groups, > > but we should bear these points in mind: > > > > - GSoC 2006 taught us that community was important in an open source > > project. Among other things, for an open source software project to > > thrive, it needs to be able to attract new users to the community, as > > well as being able to keep them. Therefore, it makes sense to have a > > site aimed at attracting and informing new and current users. > > - The long term viability of any open source project is related to > > its ability to not just attract users, but also developers. While > > some open source projects seem to directly engage people who are > > already professional or otherwise experienced software developers, > > XMMS2 seems to appeal to those mostly in and around the 'college/ > > university student' demographic. I think there are some reasons for > > this particular situation... Music players have been done to death > > over the past decade - most hardcore coders aren't really interested > > in this anymore. The 'college/university student' types are likely to > > be the kind of people who do have an active interest (as well as > > time!) in discovering, collecting and listening to new music. > > Conversely, since music players have been done to death, relatively > > new programmers can quickly learn from the vast pool of knowledge > > accumulated by others over the past decade. But this is digressing > > almost into another post.. The point is that XMMS2 has a strong > > appeal to relatively new programmers interested in exploring new ways > > of experiencing their music collection. This has been quite well > > reinforced by XMMS2's participation in Google's Summer of Code over > > the past 2 years. Therefore, there is a certain culture of education > > around XMMS2, where newbie programmers join up and help where they > > can, and progressively grow their own skills while helping the > > project. This can be represented in the site design by providing > > steps for, and encouraging, users to gradually become more involved > > as developers. (thus reinforcing the overlap between users and > > developers typically found in open source projects) > > > > > The user side should be straightforward, catchy, and it should give a > > > good idea of what XMMS2 is and why anyone would want to use it. It's > > > not a trivial thing to do, as it will require us to clearly highlight > > > what XMMS2 strengths are for a user, and how to explain it in simple > > > terms. The sections and pages should be few, simple and to the point. > > > And sexy! :-) > > > > > > The link to the developer side should be easy to find, but indeed, the > > > whole developer site could be dissociated entirely; different design, > > > possibly different subdomain, more wiki features exposed. It could > > > probably be less rigid, but if we can keep some order and hierarchy, > > > it would be nice. > > > > I think the challenge would be in structuring the information in such > > a way as to minimise duplication between the user facing side and the > > developer facing side, since duplication would simply add to the > > maintenance workload. One thing I'm thinking we might be able to do > > is basically to still use mediawiki, but more in a CMS type role.. > > That is, the content still goes into a single wiki, but the styling > > and functionality are different based on which subdomain or section > > of the site you're viewing. > > > > Cheers. > > -S > > > > > > > > -- > > _______________________________________________ > > Xmms2-devel mailing list > > [email protected] > > http://lists.xmms.se/cgi-bin/mailman/listinfo/xmms2-devel > > > > For once, I'm in good agreement with you and Sébastien. One thing I > would like to address, though, is that you mention that maintenance > difficulty worried you before, but you don't really offer a solution > to it. And you also mentioned since you haven't been maintaining the > wiki, little has been updated. Perhaps that's *because* you haven't > been maintaining it, rather than because of a lack of new information. > > I have to get to work now, but I have some ideas to get us started > which I'll post in a minute. > > -- > Dan Chokola >
Work took longer than expected. :) It's time we gave higher priority to things like Daniel's documentation work. If his documentation generation is automated on the server, there's one less thing we have to worry about. Considering that documentation is about 50% of the important material for developers, this is a big thing. Next we might want to prioritize getting a decent bugtracker and maybe some gitweb integration. These tools should all be made available on the developer website and the bugtracker should be easy enough for the user and made available on the user site, too. Automated snapshots, perhaps even a buildd, would benefit the user (show what's working on which platforms and allow easy downloads without git). This is all crap we can get done ourselves and then say to our website architect, "Hey, link to this crap in a sensible fashion." What other information can we provide automatically or more easily? Keeping the wiki updated has been a big problem, especially since we have been so dependent on Sham, who is not very available to us anymore. BTW, I'm focusing on the developer side a lot because these issues have been floating around for a long time already and would greatly simplify things. Plus, I think Tobias is already moving in a great direction on the user side of things. -- Dan Chokola -- _______________________________________________ Xmms2-devel mailing list [email protected] http://lists.xmms.se/cgi-bin/mailman/listinfo/xmms2-devel
