> I'm opposed to this. Firstly, unless I've missed something whoever gets the position, would definitionally get it before they've done anything!
To respond to just this bit: you're right, but the reason whoever gets this position has done nothing to date is that they weren't "allowed" to. Wilson was the owner of the design, and no one else could contribute to it (at least not in any significant way). Not until the past 48 hours has the idea of anyone but Wilson working on the design stuff in Django been a serious possibility. You can't hold the fact that someone hasn't done anything against them if there's nothing they possibly could have done. On Feb 6, 4:56 pm, Alex Gaynor <alex.gay...@gmail.com> wrote: > On Sat, Feb 6, 2010 at 5:03 PM, Idan Gazit <i...@pixane.com> wrote: > > Hey folks, > > > Splitting off > > fromhttp://groups.google.com/group/django-developers/browse_thread/thread..., > > which has an exhaustive discussion about how django needs to treat > > design work. > > > In the spirit of taking action, I put together this list with Bryan > > Veloso. My goal is to spark a discussion that will lead to appointing > > somebody with a few clear goals. > > > "Django Design Czar" > > > Rationale > > * Good design, like good code, is hard to produce. > > * Reviewing design is outside the purview and abilities of the core > > devs. > > * The admin is dated, and in need of cleanup/refactoring. A good job > > would involve major breaking changes, and therefore fits more in the > > 2.0 timeframe -- but there's a lot of baby steps we can take to clean > > up the existing admin in the meantime. > > * Imposing django's sensibilities on the design process requires a > > "design czar" in much the same way as we have specific core devs > > "responsible" for large django subsystems. > > * Both the baby-steps and the 2.0 "ground-up" redesign will, like > > every other part of django, be much more likely to succeed with a > > designated parent to shepherd it into existence. > > * Django can take the lead in integrating designers, not just coders, > > into the development model of django. > > > Responsibilities > > * Wearer of the "design hat." Will serve as the go-to for proposals > > and tickets that involve front-end code. > > * Serves as a "design arbiter" -- needs to be somebody that the core > > devs trust to make design decisions in the spirit of django's > > development process (relatively conservative, "does this solve a > > problem", etc). > > * See "Action Plan" below. > > > Action Plan > > > * Trivial changes, such as margin/padding corrections, should be fair > > game for committing outside of the normal release schedule, in the > > same vein as documentation corrections. > > * For 1.3, let's set some modest design goals as part of the > > development schedule. The community might not realize that submission > > of "design tickets" is something we're keen on without a little > > prompting. Design proposals are accepted/voted upon like other > > features on the 1.3 table, but we need to help jumpstart by seeding > > the list with some (modest) design proposals. > > * For 1.4, design proposals are accepted/voted upon like every other > > feature. Hopefully by this timeframe, the design czar has become > > visible enough that django is fielding quality design proposals > > without prompting. > > * In the 2.x timeframe, design czar should coordinate the effort to > > reimagine the admin. It will likely be a long-term branch of django > > much like multi-db was, as this won't likely be an evolutionary thing. > > * Hopefully we'll gain a lot of wisdom during the 1.x refactors that > > we can apply towards the 2.x ground-up rewrite. > > > "What are some good targets for 1.3?" > > > Off the top of my head: > > > * Importing some of the good work done for django-grappelli, in > > particular leveraging the fact that we have jquery in the admin now. > > * Applying a grid to the admin, even if we don't make significant > > changes to the overall "look" -- this would set the stage for further > > changes in 1.4. > > * Anything which will send a signal to the community that we're > > putting a Real Process in place to keep the admin state-of-the-art > > (while not sacrificing Django's stability/compatibility pledges). > > > Thoughts? > > > -I > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django developers" group. > > To post to this group, send email to django-develop...@googlegroups.com. > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/django-developers?hl=en. > > I'm opposed to this. Firstly, unless I've missed something whoever > gets the position, would definitionally get it before they've done > anything! This is completely antithetical to the spirit of open > source, meritocracy. Why should design be treated any different from > other changes to Django? Changes to the design of the admin should be > handled in the same way as any changes, for a large change someone > writes up a proposal, starts work, asks for review, finalizes, and it > gets committed. That being said there is no reason a designer > couldn't have a commit bit, Wilson certainly does, but they'd have to > earn it the same way anyone else does. We don't need a formalized > process to get input from designers we trust, I ask for review from > tons of people who have no formal standing in the Django community > when I have questions that pertain to their area of expertise. > > In conclusion, there is 0 reason design needs to be treated different > from a procedural perspective. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your > right to say it." -- Voltaire > "The people's good is the highest law." -- Cicero > "Code can always be simpler than you think, but never as simple as you > want" -- Me -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
