Very interesting points. Does anyone have any thoughts on using Google code hosting for this idea? Anyone know off the top of their heads whether or not we'd be able to create a Django "category" within Google or would it just sort of be lumped in with all the other Python stuff?
Sean On Sep 8, 2006, at 9:59 PM, Jeff Forcier wrote: > > I'd like to note that this is not the first time this has come up, > although I don't wish to imply we should not be discussing it (it > seems > to be one of those issues that comes up periodically). > > > http://groups.google.com/group/django-users/browse_frm/thread/ > 5e5a61a14c2e519a > > There was also a discussion on IRC from even farther back: > > http://simon.bofh.ms/logger/django/2005/11/18/09/17 > > I actually wrote up some random thoughts about this issue on a > personal > wiki page, and I figure I might as well throw those out now. Apologies > for the length and the formatting (it's obviously in wiki source > format). > > ---- > re: "Djangoforge" > > [The links I shared above were also pasted here at the top of the > page] > >> From that discussion plus a handful of others, it looks like an > official one ''is'' planned for the 1.0 release? > > * Should it be official or unofficial? > ** If it's official, that would be "nicer" because there would be a > mandate for it, it would be in a central location along with > everything > else, etc. > ** However, if official, we might run into the problem of people > expecting official support for the non-core-dev-written code contained > therein. This is probably the #1 reason to make it unofficial--or not > to have it at all, since even an unofficial one would really need > to be > linked from the official site, and thus gain officiality by > association. > *** So then the question becomes, is its usefulness going to outweigh > that support concern? > ** Also, I found a reference on the IRC channel from 2005.10.03 > quoting > one of the core devs as saying such a thing would be a "conflict of > interest" but that they'd be happy to have someone else host it. If > still true, this would make this official/unofficial issue moot (and > the wiki-related items below would have to pertain to some non-Django > wiki). > * What should it contain? Most of these are possibilities, I'm not > necessarily saying I think they should all be included. > ** Anything that does not belong in the core "contrib" directory, > stuff > that is not in the official trunk code. I.e. when someone says "Why is > Common/Useful Feature X not in Django?" and the core devs do not want > to include that feature in the short/long term, someone could make one > (app/templatetag/patch) and stick it on the Djangoforge. > ** Common model examples and/or fleshed-out explanations of the ones > already included in the docs. For example, how to do tags correctly > (and/or a small discussion of the different approaches to that problem > and their pluses/minuses). > ** Common templatetags, such as ones for len(), 'if x in y', etc. > ** Full applications, probably the primary reason people mention this > sort of project. Blog, photo gallery, wiki, etc. > * What format should it be in? > ** Is there a good reason NOT to have it in the code.djangoproject > wiki? I'd say that depends on exactly what is provided (see previous > point re: what should it contain?). For simple stuff like code > snippets > (templatetags, model layouts) we already have many on the wiki. Full > apps/projects would be something else--yes, you can attach archives to > wiki pages, but we probably want source control for this stuff, right? > *** Furthermore, the wiki provides, well, a wiki--built-in discussion > and unlimited expandability by the users. At least some of a wiki's > functionality is really required for this sort of thing, IMO. > ** Should we use whatever OSS "Forge" systems already exist? I have > not > examined them closely, but my gut instinct from using them to some > degree is that they're kinda "loud" UI-wise, plus they aren't as > collaborative as we might need (which brings us back to the wiki). > However, if good ones exist, they have theoretically solved all these > problems before and we might not want to reinvent the wheel. > ** Roll something new (with Django, of course)? See previous point re: > reinventing the wheel; but a roll-our-own could, of course, provide > exactly the features we need in the way we need them (note to newbies, > this duality of thinking is why the open source community is so damned > fragmented ;)). > > ---- > > Regards, > Jeff > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
