[02:01]  * sinzui kicks about the channel wondering if he is alone
[02:02] <flacoste> hi
[02:03] <sinzui> I am not alone!
[02:03] <flacoste> anybody here for the Q&A session?
[02:03] <flacoste> otherwise there seems to be a bad failure in buildbot
[02:04] <sinzui> With thumper off, I do not think their are any launchpad-code hackers about at this  time
[02:04] <flacoste> right
[02:05] <flacoste> cancel it?
[02:05] <sinzui> But I hope that anyone who is watching launchpad change has a question that I can answer
[02:05] <flacoste> postpone?
[02:05] <flacoste> wait and see?
[02:05] <sinzui> I am up at this time hacking on 3.0. I it is no bother to linger
[02:05] <sinzui> michael and jono will not be attending. I have been talking the thumper every day about 3.0
[02:06] <sinzui> So I was hoping to practice answers with a small antipodean crowd
[02:09]  * sinzui kicks about the channel wondering if he is alone
[02:14] <flacoste> looks like it
[02:15] <wgrant> sinzui: You listed the wrong channel in #launchpad-dev.
[02:15] <sinzui> I did where shoule I be
[02:16]  * sinzui looks at email
[02:16] <wgrant> I interpreted the ' meeting' in '#launchpad meeting' as being a typo.
[02:16] <wgrant> As in, a dupe word.
[02:17] <sinzui> I see #launchpad-meeting
[02:17] <sinzui> I will answer questions any where
[02:18] <sinzui> wgrant: I did file about about the missing query information from the edge and lp.net pages
[02:18] <wgrant> sinzui: I saw that; thanks.
[02:19] <sinzui> wgrant: I merged two sections and wrongly guarded everything
[02:19] <wgrant> where are the breadcrumbs going in UI 3.0? That wiki page still lives on wiki.c.c.
[02:19] <wgrant> Between the branding/watermark/location/blah and app tabs?
[02:20] <sinzui> We do need to move that. There is nothing secrete and a lot teams have not seen it since it is in a awkward place to go
[02:20] <sinzui> The mockup that I have seen place the breadscrumbs under the wrongly named heading-slot
[02:21] <wgrant> Which heading is heading-slot?
[02:21] <wgrant> There are three that could be incorrectly called that.
[02:21] <sinzui> yes.
[02:21]  * wgrant checks the template.
[02:21] <sinzui> https://edge.launchpad.net/launchpad-registry
[02:22] <sinzui> ^ There should be breadcrumbs under the Green <h1>The Launchpad Registry
[02:22] <wgrant> Under? That doesn't sound right. Won't that sometimes be 'Edit The Launchpad Registry'?
[02:22] <wgrant> Or is that the odd grey heading which appears rarely?
[02:23] <sinzui> If you were to view a form page The breadcumbs are in the same place, but the heading above it is demoted to a <h2>
[02:23] <sinzui> The form label becomes the <h1> an is under the breadcrumbs
[02:23] <wgrant> Ah, that makes sense.
[02:24] <sinzui> Think of the three heading as 1) a watermark 2) a context heading and 3) the page title/heading
[02:24] <wgrant> sinzui: Should the context and page headings be omitted if either is the same as the watermark?
[02:24] <wgrant> 'cause they're not on the new pages, and it looks silly.
[02:25] <sinzui> But this is still hard to engineer and review because both parties must know when to pass the page title/heading to the heading slot to prevent duplicate titles
[02:25] <sinzui> Your question has not been settled. The answer is no, but I do not think anyone likes that answer
[02:26] <sinzui> The case you point out is a pillar, person, or top-level colllection.
[02:26] <wgrant> The project edit and index pages, for example, look pretty strange with the differently duplicated headings.
[02:26] <sinzui> yes they are
[02:26] <wgrant> But I suppose otherwise the descendant objects would have different numbers of headings for their edit forms.
[02:27] <sinzui> To combine the watermark heading and the context heading requires some clever work because editable titles cannot be autocreated by the layout
[02:28] <sinzui> wgrant: If we solve the editable title issue, I think we would consider dropping the context header
[02:29] <wgrant> sinzui: Oh. I thought the watermark would get an inline edit link. But that idea formed in my mind before I realised how shallow that heading was.
[02:29] <sinzui> Right
[02:29] <sinzui> We will solve this, but I am not certain we will do it for 3.0
[02:30] <sinzui> We need to make the logo editable in the page and we need to communicate it is editable
[02:30] <sinzui> We have an idea EdwinGrubbs will start work on in the next two weeks
[02:31] <wgrant> Good, good.
[02:31] <sinzui> The registry will loose its colur
[02:31] <wgrant> Hm?
[02:31] <sinzui> Answers will get a colour refinement
[02:32] <sinzui> The reason is that blue and green mean links in Launchpad .
[02:32] <wgrant> Ah.
[02:32] <wgrant> I noticed that the Blueprint and Answers involvement link colours are too close to the background for my liking.
[02:33] <sinzui> indeed that bug has not been filed.
[02:33] <wgrant> The new project index view also exposes the wrong release for download.
[02:34] <sinzui> The set answer contact page is very confusing because it is just links and headings-- blue ans blue on white.
[02:34] <sinzui> really?
[02:34] <wgrant> Yes.
[02:34] <wgrant> It was showing bzr 1.18rc1 until today.
[02:34] <sinzui> That comes from a query that was considered proven
[02:34] <wgrant> But that's a flaw in the data model :(
[02:34] <sinzui> The rdf link is a problem
[02:35] <wgrant> I think it needs to die.
[02:35] <wgrant> Or go down the bottom
[02:35] <wgrant> Or just generally hide.
[02:36] <sinzui> I argue that we move into the <project|distro|projectgroup> information portlet since the info is an alternate of the portlet info
[02:36] <sinzui> poolie and I discussed dropping RDF.
[02:36] <wgrant> It certainly doesn't belong in the Downloads portlet.
[02:37] <wgrant> And it causes it to show up on projects where it makes no sense.
[02:37] <sinzui> I was strongly inclined to do it since the FOAD and DOAP is useless from my inspection
[02:37] <sinzui> I found that there are a minority of users who are using it
[02:37] <wgrant> If people know what FOAF and DOAP are, they can probably find an obscure link.
[02:37] <sinzui> s/FOAD/FOAF/
[02:37] <wgrant> FOAF was useful once upon a time.
[02:38] <wgrant> And I think REVU might still use it.
[02:38] <sinzui> My fallback proposal was to add a meta instruction to the page to indicate there is an RDF alternate for the page
[02:40] <sinzui> We need help converting blueprints
[02:41] <sinzui> It is assigned to the registry team, but my team already has 3 times more templates than other teams
[02:41] <wgrant> I considered working on some Blueprint stuff. But, well, I think Blueprint needs to go away and be subsumed into Bugs.
[02:41] <sinzui> I am told that that is unlikely
[02:41] <wgrant> Damn.
[02:42] <sinzui> I think the next best thing is to give them feature parity so that the similarities make the argument more compelling
[02:42]  * thumper reads scrollback
[02:42] <sinzui> I am sure blueprints would be more successful if it's statues, events, and email were like bugs
[02:43] <wgrant> Blueprint and Bugs each have sets of unique features, all of which would be useful for the other.
[02:43] <sinzui> No one has brought up the NavigationalMenus, the bane of every developer's existence
[02:43] <wgrant> Are NavigationMenus those grey-turned-black things that lurk at the top of the old pages?
[02:44] <sinzui> There is a request to create a small task/todo application. It is assigned to the registry for evaluation
[02:44] <sinzui> YES they are
[02:44] <sinzui> There are many names for them.
[02:45] <wgrant> And they are very confusing and easy to miss.
[02:45] <wgrant> It takes ages to work out how to alter a person's OpenPGP keys.
[02:45] <sinzui> Looking at the designs we (me) assumed they would go away, a failed 2.0 experiment
[02:45]  * thumper never like the navigational menus in the first place
[02:46] <sinzui> mpt did. beuno announced they were going away on the day he took over the UI
[02:46] <wgrant> sinzui: To what level should I be filing bugs on new UI bugs?
[02:47] <wgrant> eg. the unconditional "padding-bottom: 0.3em" on 3.0 <li>s, which makes the actions portlet too tall.
[02:47] <sinzui> We are being pretty details. I have bugs for each portlet I am working on
[02:48] <sinzui> Engineers started speaking up on the CSS  this week. I think we have all seen enough to know what does not work
[02:48] <sinzui> The <h2> elements were updated today I think
[02:48] <sinzui> We should have bugs on these  issues.
[02:49] <sinzui> There was an accidental reuse of of the summary class that makes search results look very large
[02:50] <sinzui> wgrant: when I change a detail, I search the bugs to see if I can fix something else at the same time
[02:50] <wgrant> The same thing happens on ArchiveActivateView when there are existing PPAs.
[02:50] <sinzui> The registry had 50 UI bugs when this started. I think we should try to solve all of them
[02:51] <sinzui> was that converted?
[02:51] <wgrant> It was.
[02:51] <sinzui> damn
[02:51] <wgrant> But the view it uses to list the PPAs wasn't.
[02:51] <wgrant> Yet.
[02:51] <wgrant> It's the same listing view that's used on the person index, so it should be fixed when that goes 3.0.
[02:52] <sinzui> I can adjust the CSS rules. I think this also relates to the overlap of object attributes
[02:52] <sinzui> title and displayname, summary and description and homepage
[02:53] <wgrant> Oh, also, the project summary looks far too fat here.
[02:53] <wgrant> Am I the only one who thinks this?
[02:54] <sinzui> I am uncertain.
[02:54] <sinzui> I think the issue is how much info was put in it
[02:55] <wgrant> The description of the summary is lacking, and I'm not sure if any existing projects do it properly.
[02:55] <wgrant> Actually, launchpad-project's works very well.
[02:55] <sinzui> I agree
[02:56] <wgrant> launchpad-registry... not so much.
[02:56] <sinzui> I have been meaning to rewrite the registry
[02:56] <sinzui> It was given to me. I like Ed' RDF work, but the registry is not really about that
[02:57] <wgrant> Maybe it was initially.
[02:57] <sinzui> yes there are foaf and doap directories in the tree still
[02:57] <wgrant> Huh. I thought those were removed ages ago.
[02:57] <sinzui> after 3.0 I think we can rename some directories
[02:58] <sinzui> We are stilling find tests and templates in the wrong place. The effort to update everything is making us clean up a lot
[02:58] <wgrant> I've seen a lot of stuff in canonical.launchpad that should really be moved out to the app packages. :(
[02:58] <sinzui> yep
[02:59] <sinzui> That is officially the foundations team, they have had other priorities over the past year
[02:59] <sinzui> thumper and I started moving items there because it is frankly easier to find
[03:00] <wgrant> Mmm. It has definitely made it rather harder to find, but that's just because everything is spread around horribly.
[03:00] <sinzui> everything in canonical/launchpad/webapp should become canoncial/lazr The code is too intermixed to separate it easily
[03:01] <sinzui> webapp/tales is getting lot of work. We should try to move that soon. Maybe give up on lazr and move it to lp/app
[03:02] <sinzui> There are a lot of old tests or unowned code that needs sorting out in c.l
[03:03] <sinzui> I think structural subscriptions should become the registry's domain
[03:03]  * sinzui would like to take sprints form blueprints too
[03:03] <wgrant> They should.
[03:03] <wgrant> Shouldn't c.l.webapp.tales be cut into lots of pieces and thrown into different apps, rather than all going into lp.app?
[03:03] <sinzui> I am adding links to create sprints from the series pages
[03:04] <thumper> wgrant: yes it should
[03:04] <sinzui> absolutely.
[03:04] <thumper> wgrant: I did the first yesterday
[03:04] <wgrant> sinzui: I don't think it's a good idea to link to sprints before they're improved.
[03:05] <sinzui> There are some ancient tests (canonical/launchapd/doc/menu.txt comes to mind) that can be dismantled because they duplicate other tests
[03:05] <sinzui> wgrant: yes, I would commit to fixing them when I move them
[03:06] <sinzui> I do not think the need to be dependent on blueprints. There are date and report issue that need fixing
[03:06] <wgrant> Why has the bounty tracker not been purged completely like the calendars were years ago?
[03:07] <wgrant> Or is it meant to maybe be revived at some point?
[03:07] <sinzui> there was some thought about resurrecting it.
[03:07] <sinzui> well that thought certainly died before 2.0
[03:08] <sinzui> We are driven to work on business priories. while 20% of our time should be spent one clean up the code and tree, I do not think it is being done my every engineer
[03:09] <sinzui> It would have been cleaned up if it was a specific team or person's responsability
[03:09] <sinzui> It is going to be removed either by the registry team or the soyuz team because we have bounty templates we are obligated to remove
[03:10] <wgrant> Ah.
[03:11] <sinzui> I do not have access to the script that generates the progress report
[03:11] <sinzui> It shows the templates that need converting
[03:11] <wgrant> The one on devpad run by mars?
[03:12] <sinzui> yes
[03:12] <flacoste> there is a branch for it
[03:12] <sinzui> That would be nice
[03:12] <sinzui> We can push the static ajax data and the output file to a public location
[15:00] <sinzui> Do I dare start a meeting
[15:01]  * beuno cheers
[15:01] <sinzui> Well
[15:01] <sinzui> time to start
[15:02] <sinzui> #startmeeting
[15:02] <MootBot> Meeting started at 09:02. The chair is sinzui.
[15:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:02] <bigjools> me
[15:02] <sinzui> Let's try a rollcall just so I know how many people are listening
[15:03] <sinzui> ha
[15:03] <noodles775> I'm here to learn from any discussions too!
[15:03] <beuno> me
[15:03] <deryck> me
[15:03] <bac> me
[15:04] <sinzui> I seem to have missed jtv in both sessions
[15:04] <sinzui> okay. we can start.
[15:05] <sinzui> Does anyone have a question about UI 3.0
[15:05] <sinzui> I will ask a question then
[15:06]  * bigjools raises hand
[15:06] <sinzui> beuno: The registration information should appear in the header. bug should it appear all the time? I am certain it should appear for an index  of a context object, but what about a alternate view of it?
[15:07] <sinzui> s/bug/But/
[15:07] <beuno> sinzui, I think only on the overview
[15:07] <beuno> it's not that important
[15:08] <sinzui> beuno: when I look at the mirror listing for a distro, should I see then the distro's registration info
[15:08] <sinzui> beuno: it is for some tests, but only on the index
[15:08] <bigjools> this sort of thing breaks down a bit on the packaging pages
[15:08] <beuno> so there's your answer
[15:08] <beuno> "only on the index"
[15:09] <sinzui> That is easier to do. I can provide both automatic rules and a slot to override it
[15:09]  * sinzui worries about every page.
[15:09] <sinzui> thanks beuno
[15:09] <sinzui> bigjools: you have a question?
[15:10] <bigjools> is there a general plan to deal with the type of objects that have no narrative to show under the title?
[15:10] <sinzui> I do not think so
[15:11] <sinzui> rockstar: has a similar issue with answers, where the narrative should not be separated from the comments, so the details is first
[15:11] <bigjools> in a page I was doing mechanical changes to, the distroarchseries index, there's no narrative, and I need to go straight into a two column grid
[15:12] <sinzui> That can happen with milestones and releases too
[15:12] <sinzui> bigjools: their narrative is optional, so the design must DTRT
[15:12] <bigjools> what is DTRT in this case?
[15:13] <sinzui> beuno: Have you seen a design that we can use to implement without thinks for objects we are not redesigning?
[15:13] <bigjools> yeah, that'd be nice, since I have a few pages that have details portlets that I need to move inline somewhere
[15:14] <sinzui> bigjools: I do not know. I think the infrastructure or design rules should be clear enough that I do not need to think
[15:14] <sinzui> bigjools: that is exactly the problem that rockstar encountered
[15:14] <sinzui> bigjools: is this issue blocking DSP?
[15:15] <bigjools> not really, I think we've settled on that now
[15:15] <sinzui> because we found a sentence to start the page with?
[15:15]  * beuno reads the scrollback
[15:15] <bigjools> sort of, I gave it a "This package has XXX new bugs and XXX open questions"
[15:16] <beuno> could I see a screenshot or a page of this?
[15:16] <beuno> I'm not sure I fully understand it
[15:16] <sinzui> I ponder what this means about these kids of artefacts. Do we consider them self-explanatory?
[15:16] <bigjools> have a look at https://edge.launchpad.net/ubuntu/jaunty/i386 and tell me how you would redesign it
[15:17] <sinzui> bigjools: distroarchseries is the i386 details of karmic?
[15:17] <bigjools> beuno: you've already seen that DSP page quite a few times  :)
[15:17] <bigjools> sinzui: it exists to be able to do binary package searches for that architecture
[15:18] <bigjools> but it doubles as an index I guess
[15:18] <sinzui> does it really need it's own page then (I know you do not want to invest a lot of time)
[15:18] <bigjools> exactly, this was supposed to be a simple mechanical change :)
[15:18] <beuno> bigjools, I think that moving the information beneath the search box is TRTTD
[15:18]  * sinzui merge milestones and releases to reduce duplication
[15:19] <bigjools> beuno: yeah, I have it to the right at the moment, it doesn't look quite right
[15:19] <bigjools> it also has a separate template for +search that is 95% the same as +index, so I merged them
[15:20] <beuno> bigjools, it sounds like we need a better answer for moving that type of portlet into the content rather than the description-less issue
[15:21] <bigjools> I onlt mentioned the description-less stuff because curtis said it looked weird on the DSP page :)
[15:21] <bigjools> but yeah, this is another issue to work out
[15:22] <beuno> I don't think the lack of description in itself is a problem
[15:22] <bigjools> the question was whether it was good or not to put a two-column portlet arrangement immediately below the title
[15:23] <beuno> not in this case
[15:25] <sinzui> So do we want to set this as an action item to define a no-think-required way to handle narrativeless pages?
[15:25] <beuno> that means more work for me, so I'm not 100% sure of it
[15:26] <bigjools> heh
[15:26] <beuno> but I will work with someone to figure out a pattern  :)
[15:26] <sinzui> I think the issue is that a page cannot start with two columns, so we must always have a piece of content that can be used as a top-portlet
[15:26] <bigjools> so I think what I did on the DSP was fine
[15:26] <bigjools> even w/o the extra text I added
[15:28] <bigjools> we could do with some styling to bottom pad the <h1> in the main content though, it butts up too close to the rest of the content
[15:28] <sinzui> bigjools: by making the search the first content and it span all main, does this create a second problem? That the arch information is now spanning two columns and it creates unwanted whitespace?
[15:28] <beuno> maybe it doesn't need 2 columns?
[15:28] <bigjools> sinzui: I've not tried that layout yet, I started with a two column arrangment to see how it looked
[15:29] <beuno> bigjools, I think that there's no padding because breadcrumbs are coming, and they will have it
[15:29] <bigjools> coolio
[15:29] <sinzui> 2 columns is optional, never required
[15:29] <bigjools> the other thing is that I know beuno will hassle me for just moving the details portlet inline as it doesn't look that good
[15:29] <sinzui> I believe that many listing/collection pages will never use 2 columns
[15:29] <beuno> I like being predictable
[15:30] <bigjools> which means making it a 2-column <dl> I guess
[15:30] <noodles775> I have a question too - has anyone opened a bug for the watermark heading (h1/h2) issues that we've always known about, but not yet had time to fix? (ie. https://edge.launchpad.net/ubuntu/+search)
[15:30] <sinzui> bigjools: I expect the details/info to be in the upper left of every page.
[15:30] <bigjools> sinzui: that would displace the search form
[15:30]  * sinzui does not want to search the page for that information
[15:31] <sinzui> bigjools: I ti not the first item on any approved design
[15:31] <bigjools> I think search forms should always be at the top
[15:31] <sinzui> bigjools: it is the second
[15:31] <bigjools> for example, the search form on the distro index page mockup was in the wrong place for me
[15:32] <sinzui> bigjools: the general rule of pages (on the whole WWW) is first state what the page is about, then provide some details. then provide things that you can do
[15:32] <sinzui> bigjools: It has not been approves
[15:32] <sinzui> bigjools: It has not been approved
[15:33] <sinzui> bigjools: we will discuss that design today. The issue is not just the importance of the field, but the links that relate to it
[15:34] <bigjools> ok
[15:34] <sinzui> bigjools: if we do not place content is a consistent manner, users will report a bug.
[15:34] <bigjools> so beuno said above that on my DAS page the search should come ahead of the details
[15:34] <sinzui> bigjools: so if we try to make an exception, we should be prepared to unmake it if users point out the issue
[15:35] <beuno> well, because I feel that those aren't really details, as the title really asys it all
[15:35] <beuno> says, even
[15:35] <sinzui> and I say the detail comes after it like the pillar pages
[15:35] <bigjools> indeed
[15:36] <bigjools> oh I should also mention that the search results come at the bottom of the page now
[15:36] <bigjools> since I removed the ridiculous second +search template that was 95% similar
[15:36] <beuno> so that's another reason to place the info beneath the search feild
[15:36] <beuno> so you don't move it around on the page when searching
[15:37] <bigjools> it won't...?
[15:37] <bigjools> you'd just have:
[15:37] <bigjools> ______________ SEARCH
[15:37] <sinzui> the details is also below the search results
[15:37] <bigjools> [info]
[15:37] <bigjools> [results]
[15:37] <beuno> no, I think the details should go when you search
[15:37] <bigjools> argh
[15:37] <beuno> :)
[15:38]  * sinzui this thinks is the same as when a project puts 8 paragraphs of homepage content, pushing project details below the fold.
[15:38] <bigjools> so much for "no-think" changes :)
[15:38] <bigjools> this is why I put the info on the right!
[15:38] <beuno> well, there always some thinking, otherwise sinzui would just write a script that did all the work
[15:39] <bigjools> lol
[15:40] <sinzui> I assume that someone has read the details before searching. Once the user has searched, the results are the most important
[15:40] <sinzui> I think search, results, details is the best order in the circumstance
[15:41] <bigjools> or in a side portlet...
[15:41]  * bigjools hides
[15:41]  * sinzui gets nightvision goggles
[15:41] <noodles775> lol
[15:42] <sinzui> bigjools: are you concerned that the details are below the fold after a user  has searched?
[15:42] <beuno> details are clutter and distraction in a search results page
[15:42] <sinzui> beuno: that is my point
[15:42] <bigjools> below the fold is fine with me
[15:42] <sinzui> we know the user is only going to look at the results
[15:43] <beuno> bigjools, it can't be that hard to only how the details if there's no results
[15:43] <bigjools> beuno: yeah easy to fix
[15:43] <beuno> good, then it's done!
[15:44] <bigjools> it just goes to show there's no such thing as a mechanical change, even on the most trivial of pages
[15:44] <bigjools> look at the damn thing...
[15:44] <bigjools> it's gone a search form and a details portlet FFS :)
[15:45] <sinzui> We have discovered a rule that collections can place alternate links to lists in the side portlets. /people and /project will use this
[15:45] <barry> and /projectgroups /distros /sprints
[15:46] <sinzui> beuno: Question listing and bug lists also have alternate views of the list. can they be in the side portlets too?
[15:46] <barry> to refine: beuno suggested no info icon and a very simple word for the links (e.g. People)
[15:46] <beuno> sinzui, I think intellectronica has listed them as such in his mockup, yes
[15:47] <sinzui> he did
[15:47] <sinzui> I suggest to bac to move them inline for the mirror listing pages. he may want to reconsider
[15:47]  * sinzui thinks the two links looked better inline
[15:48] <bac> yeah, they do look good in-line
[15:48] <sinzui> beuno: the +global-action view that makes the side portlet links never generates a header because it si always first.
[15:49] <sinzui> beuno: since there can be two portlets of links, should we have an alternate layout that add the menu title?
[15:50] <barry> sinzui: in the examples i've done, i don't think a menu title would be useful
[15:51] <beuno> sinzui, if things are clearly grouped by actions and links
[15:51] <beuno> I don't think a heading is needed
[15:52] <sinzui> I am happy to not make an new named view
[15:53] <sinzui> beuno: is there are rule for the use of "view" and "show" in link text?
[15:53] <sinzui> "View" takes you away, "show" is inline/ajax
[15:54] <beuno> sinzui, I wouldn't use them unless they're part of a phrase
[15:54] <beuno> I think the color of the links should be the ones that tip you off what it's going to do
[15:54] <sinzui> The use of view and show see arbitrary
[15:54] <beuno> although I agree that "show" should only be used for inline actions
[15:56] <sinzui> We prefer "register" over "create" since in may cases, launchpad is modeling what has happen in the real world.
[15:56] <sinzui> Are you registering a milestone or creating it?
[15:57] <sinzui> for projects this semantic difference many imply placeholder versues hosted projects
[15:57] <beuno> true
[15:58] <beuno> I think my brain is telling me that I want to create a milestone
[15:58] <beuno> but I think you're right that we model reality rather than crate it
[15:58] <sinzui> beuno: I bring this up because we are doing a lot of menu reporganisation. a link might uses a different term in two different menus.
[15:59] <beuno> sinzui, yes, it's grat that you do
[15:59]  * sinzui needs to pick a term and update the old tests
[15:59] <beuno> sinzui, I think I'd use create, as it's clearer for users
[16:00] <beuno> and, not use "view" in a link ever, and only "show" if you need to for inline displaying
[16:00] <bac> "create" something in LP, "register" something external, like a mirror
[16:01] <beuno> "register" sort of feels "sign up"-ish to me
[16:01] <sinzui> beuno: but "view" is the action in all th top-level listings?
[16:01] <beuno> sinzui, not after I worked on it with barry  :)
[16:03] <sinzui> We have talked for an hour
[16:03] <sinzui> If no one has any further questions, I will close this meeting
[16:03] <sinzui> We can always talk on #launchpad-dev
[16:04] <noodles775> sinzui: just the one I asked before...
 I have a question too - has anyone opened a bug for the watermark heading (h1/h2) issues that we've always known about, but not yet had time to fix? (ie. https://edge.launchpad.net/ubuntu/+search)
[16:04] <sinzui> noodles775: I do not know about a bug
[16:05] <sinzui> I think we should report one so that someone can fix it
[16:05] <noodles775> sinzui: yep, doing so now.
[16:05] <sinzui> I need to report a bug about adjusting the CSS so that .summary is not giant in all cases
[16:07] <sinzui> thank you everyone for participating
[16:07] <sinzui> #endmeeting
[16:07] <MootBot> Meeting finished at 10:07.
[16:07] <deryck> thanks for hosting this sinzui!
[16:07]  * deryck lurked but found it useful.
[16:07] <beuno> thanks sinzui
[16:07] <bigjools> cheers sinzui
[16:09] <noodles775> Also, beuno, sinzui,  can we discuss the question beuno  had about https://edge.launchpad.net/ubuntu/+ppas
[16:09] <noodles775> I think cprov landed that with your approval sinzui, but beuno is uncertain about the second (default context.title) heading, which is the same as the root-context heading in the watermark.
[16:10] <noodles775> Thanks sinzui !
[16:11] <sinzui> I think cprov followed the rules. I agree it looks wrong
[16:12] <noodles775> sinzui: so, we should in that case fill the heading slot with the <h1>Ubuntu Personal Package Archives</h1> right?
[16:12] <sinzui> This is why I stopped working on the heading. The rules seem arbitrary. I cannot explain the rules, so I am not qualified to hack on them
[16:13] <sinzui> Only when we are looking the context's index page  do we override the heading-slot
[16:15] <sinzui> I expect to see a lot of this when the many team views are updated
[16:15] <bigjools> yeah it makes no sense on +ppas
[16:15] <sinzui> I do not think we should be talking about this There should be a rule in the code and it DTRT
[16:16] <sinzui> I do not know how to write the rule. thinking about is was very frustrating
[16:16] <noodles775> yes, that would be ideal - but to create that rule we have to talk about it. Yes, I can imagine it was frustrating.
[16:16] <sinzui> I decided I need to work on my team's pages
[16:16] <noodles775> Yep.
[16:17] <noodles775> Maybe an exception to the above rule could be: except when you are on a view of the root-context? (although it seems unnecessarily complex)
[16:17] <sinzui> Deep in my heart, I think this design is flawed. I was very sad when I had to add that slot. It was such a F'up in the 1.0 design
[16:18] <sinzui> I will not be surprised if 4.0 removes it again
[16:18] <noodles775> Yeah, that's not fun.
[16:19] <noodles775> I'll have a think about it and maybe run something by you on monday.
[16:19] <sinzui> noodles775: now that we have a new way if identifying the watermark, maybe we can have the context-slot never render if the context is also IPrimaryContext
[16:20] <noodles775> sinzui: but, just in case you know it yourself, everyone thinks you've done an amazing job coordinating this effort!
[16:20] <noodles775> sinzui: yeah, that's a great idea! (As there's no need for breadcrumbs - is that right?)
[16:20] <sinzui> my self-esteem is directly proportional to the number of branches I land
[16:20] <sinzui> well
[16:20] <noodles775> heh... you sound like cprov ;)
[16:21] <sinzui> I *think* that is still the rul
[16:21] <sinzui> e
[16:21]  * sinzui finds beuno to ask