GitHub recently introduced issues that are split into tasks. You can add checkboxes to the issue text and use them as a todo list. That could be used to note all the small issues that we/you are aware of, such as the JS button. I don't see the problem in opening new tickets for larger issues. Also, I highly discourage the current behaviour not to use existing or open new tickets for admin rework stuff. That effectifely stops passersby and everyone not deeply involved from helping out. It's already hard enough to keep track of what is done. We had labels not long ago for issues, there was an admin label etc, if those were used, it would be easy to find multiple tickets regarding a larger code part.
And one more thing on working on stuff and using issues. We obviously are in a state of heavy flux. We have to take care not to lose track of all the ideas and at the same time we need to focus on some parts instead of working on all of them. Otherwise, we will not get back to a usable master before the end of the year. Example: There's discussion on GitHub for reworking the entire status system. Starting work on that would massively slow down work on the admin, even if it relates to some of the admin rework issues (like, wtf is going on when a post is published). We have some milestones on GitHub. Maybe we should add some more fake milestones so we can assign more stuff to milestones and then actually work on the next milestone, and only the next one. So, what I am saying is: I don't have a solution on "how to deal with issue tracking on this topic" but I also don't think we need a different system than the GitHub issue tracker. Am Samstag, 6. April 2013 14:05:33 UTC+2 schrieb ringmaster: > > Since the topic was coming up in IRC, I figured I'd mention it > specifically more visibly. > > The admin javascript (and CSS) is going to be removed and replaced. I > specifically mention the javascript because that's the part I'm planning > to involve myself in actively. > > Obviously, others are welcome to help in this effort. The goals are to: > > * Reduce the size of the javascript. This will aid in maintainability. > * Produce better general-purpose handlers from the onset. There are > some objects we use regularly that have some special cases that need to > go. > * Integrate better with new form controls. There is at least one new > control designed to work on lists better than what we have already in > the admin javascript. > * Make use of the server-side ajax response classes. There is a useful > client-side script for interacting with the server that should be used > more, since it will give us the the ability to use simple, unified > notifications. > > In particular, the publish page is in shambles due to some now-obvious > deficiencies in the markup/script. A particular symptom of the current > issues includes some weirdness in behavior when trying to publish a > draft. The publish button doesn't seem to do anything (it actually sets > the status selectbox of the post, but doesn't submit the form), and then > the save button generates a "are you sure you want to leave this page?" > message. > > If our admin HTML was written more resiliently, this might not have been > a problem. Instead, the HTML is replete with idiotic class names, upon > which the script has become dependent. It is *imperative* that new > markup is, if not semantic, then at least *addressable by script in a > sane way*. It has been a factor of the FormUI rewrite to produce > absolute minimal HTML for this purpose. > > Also in the works with javascript: Removal of the "cool but > questionable" loupe, to be replaced with a more GMail-like search box, > with autocomplete, like this: http://screencast.com/t/1qGp1As4uO > > There is work in progress to return the admin both to a workable state, > and to re-style some things based on the new FormUI-supplied markup. I'm > not sure how we should be filing issues against the admin at this time, > since those issues are a distraction to that effort by having to deal > with continuous new issues on things that we are aware are in flux, and > also counterproductive to have passersby try to fix those issues when > we're replacing large sections of that code. (For example, it's largely > pointless to try to fix the javascript on the publish button, when the > javascript-generated publish button is going to be replaced by a real > FormUI one.) Suggestions on how to deal with issue tracking on this > topic are welcome. > > Owen > -- -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev --- You received this message because you are subscribed to the Google Groups "habari-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
