The “log out” link in the dropdown menu might be more usefully placed at the top of the menu rather than at the bottom where it says “more notifications” imo.
In Safari on an iPad, composing a post acts kind of funky. fwiw.
2 Likes
I had the same thought a few days ago, @lah7. I had a laptop with a relatively small resolution and the stuff was going over the bottom edge of the window so I had to erase firefox history to logout. xD
Actually, if anything, I’d suggest actually placing it in the top header. In between Go to another topic list or category and the user dropdown menu.
Or maybe like crankypuss suggested indeed. In the top bar of the user dropdown menu. Just to the left of Bookmarks.
It seems that Discourse by design intentionally placed the log out button at the bottom and I have to agree with that choice. Very few people would need to log out and having it too near the top is an accident for anyone who curiously clicks on it.
Clicking the profile button to open the notifications menu doesn’t go further then the screen, that is, unless you resize the window / rotate the screen while it is open.
Thanks for looking into it, Luke. I’ll endeavor to generate fewer notifications. 
I do feel something of a “duty” here, perverse as that may seem.
Without criticizing @lah7 in any way, i want to point out a phenomenon that i’m reminded of here. It’s somewhat a bunch of memories of incidents i recall from working as a developer for my entire career, but it’s probably also a matter of my personal agenda, so read objectively please, and i’ll describe where it itches as best i can.
So imagine this handful of guys responsible for creating a software product. It doesn’t matter whether they’re getting paid or not, the pressures are pretty much the same, getting paid is just the balm, imo. It doesn’t even matter whether it’s a team of 100 guys or a team of 6 or a lone developer, the algorithm i’m trying to point out is scaleable, though i think it actually works more effectively with large teams than small teams, because there’s more to keep track of.
Anyway there’s a “team” (of 1 or 100) that has obligated itself, for money, or for honor, or just the pure value of the thing the team has obligated itself to build. And there’s enough action to justify some kind of bug-tracking system (i’m against those, fwiw). Now, not only is the team obligated to doing the job, it now needs to justify itself, or prove to others, that the job is being done, in order to get the money, or the honor, or just the valuable thing being built.
So as i recall the old QA Team meetings, where bugs are tracked and blamed (oops, “resolved”) somehow. The next bug comes up in the meeting. “Yeah, i know that isn’t perfect, but these other things need fixed too, and they’re more important” is often heard in such meetings, even if it’s only in a sole developer’s head. So it’s necessary to make that bug report go away.
The proper way is imo not to track it to begin with, just fix it or say “BS”, but once you get into tracking this crap, the methods available for making it go away are (a) put the onus on the user as i’ve seen done so many times before (user error, you should know that the icon you touched means “instant security wipe” even though there’s nothing but the shape of a blob on the screen to tell you what it does and no confirmation dialog) which imo is always pretty much a cop-out unless it really is a BS bug report.
Or there’s method (b) which is to defer it to some later forever so at least it’s not on the weekly report read by those who set your pay-grade by whatever means.
Of course you can always use method © which i call “the feechur card”, well yeah, that’s messed up, but it prevents errors becalse (which is really just method [a] in disguise).
If none of that works (and usually some of it can at least be made to appear to work, which is good enough to get it out of your face until the next meeting so maybe you can get some work done) you can use method (d) and put it on the active list at some priority, thus increasing the obligation-load of all developers associated with the projejct. This is “a bad thing” because everybody is always overloaded, because that’s how you tell when the project is adequately manned, people start getting gritchy because they already have more work than they can do.
Okay, so that’s just setting the scene. All the above is just context-setting for what follows, which is what i want to say, but which probably would mean nothing out-of-context.
We’uns (all of us except those few consumers who just want something that isn’t Windows and isn’t Apple that works without embedding a hook in your guts) are working in an open-soource environment.
In this environment, there is both upstream and downstream. Upstream is where the code comes from, downstream is where it goes to. The code-owners are upstream, they are the spring from which it flows. The upstream guys are all overloaded all the time, that’s how it works when you get formalism into your system for creating code.
So here is the part, finally, that i wanted to say. When a guy is downstream from the code-source, and something is presented that maybe needs fixed, how do you handle that?
Well you’re already overloaded if you’ve made a commitment to do something that others know about, especially if you’ve decided on release-dates and made them public. Release-dates are living death imo, but that’s just my take from being run through that wringer lots of times.
The only reasonable way is to take the approach @lah7 took, to say yep, the code owners have seen this one and they found an excuse not to change it, so let’s leave it broken. AND i want it to be clear that i do not criticize here, i’m just trying to point something out as a trap to beware of stepping in, because i’ve stepped in it plenty of times myself as i recall.
In a true open-source development-environment, what might be a more useful scenario, would be for someone to step up and just fix it, then send the fixes to the code-owner. If they don’t like the fix, fork it.
Of course all that takes work. And one guy can only do so much work.
I guess what i’m doing here is calling for more involvement by those who can actually do some of the work. But that’s difficult because every project is a little different and nobody wants to go in and mess something up worse than it already is.
That’s it, that’s what i wanted to say. Those of you out there, who think something is broken, y’all might try to find a way of fixing it for yourself and your friends.
I’ll admit that makes me look the hypocrite, because what am i fixing after all, and there’s reason in that view. OTOH i’ve been working on a project for an amazingly long time if i look back at its roots, and i’m convinced that it’s going to solve more actual problems than anything else i could possibly do.
That’s the long and the long of it. Instead of patting ourselves on the back for sharing our work, maybe some of our back-patting effort should be reclaimed along with our bug-tracking effort and the whole put into making things as right as possible.
jmo, fwiw.
[quote=“crankypuss, post:6, topic:13695”]The proper way is imo not to track it to begin with, just fix it or say “BS”[/quote]That might work for smaller projects but consider, as an example, WINE. Which is an incredibly complicated piece of software, with numerous components. Not tracking the bugs, having no bug tracker of any kind would just lead to endless upon endless bug reports. All reporting the same bugs. With a tracker you have something to reference. Not only for the users but also for yourself.
And now, let’s take that one step further – the Linux kernel itself. With its ~16 million lines of code. Yeah, good luck with having no bug tracker on that one. Beyond a certain scope you need to track them. Otherwise things will just end up lost in the shuffle or get repeated time and time again. Only costing you more time in the end (time spent explaining that, yes, we know that bug exists and these are the reasons we’re not addressing it right now), time that could have been spent on actually fixing the bugs.
1 Like
I wish you had a more memorable userid than @1Q7FE6zp, it’s just too rote for my simple brain to remember.
Anyway, i hear what you are saying, and i agree about the symptoms, just not the disease.
I’ve worked on some fairly large projects. Fresh out of college in 1972 me and half a dozen other guys built a kernel for a PDP-11/45 (memory segmentation was still new in those days) in about a 9-month period time from when the first LOC was written. That also included the application development, which supported one of the initial credit-verification systems back when it was all being done by voice phone calls. There was less of it than there is of today’s linux kernel because there was simply less tech when bisync was state-of-the-art and your system drive was 128kb instead of 1Tb. The other guys were all 15+ year veterans. I wrote the line-printer driver, the fixed-head disk driver, and the filesystem, helped debug the homebrew interactive debugger and the task scheduler.
There were so few of us compared to the work involved that we didn’t get into each others’ way. We didn’t track bugs, we fixed them.
The biggest reason there are so many bugs and it’s all such a mess is bad design imo. In a properly designed system there are independent components working together. They can be fixed independently. Interfaces are defined and validated. Things are not just helter-skelter dependencies on dozens of shared libraries.
If all one’s experience has been obtained within a system that was extant when he started playing, that’s the system within which we tend to think. imo.
1 Like
[quote=“crankypuss, post:8, topic:13695”]The biggest reason there are so many bugs and it’s all such a mess is bad design imo.[/quote]Closed Source – Sure. FOSS – Not fair, imo. Again, consider WINE. These people working on it have to go with reverse engineering or sometimes even just wild guesses. For plenty of Windows API stuff, there is no readily available documentation on what happens in the background.
They’re basically reverse engineering an OS that is indeed literally rotten from the ground up ( https://securityintelligence.com/news/windows-atom-tables-blow-security-researchers-say/ ) and trying to implement a crossplatform API-esque system that is not rotten from the ground up while trying to remain compatible with that rotten system (while else even bother to make WINE, its purpose is to run Windows software).
And concerning the Linux kernel, not so sure you’re being fair there either. In the PDP days, you could indeed just write your own stuff. There weren’t an awful lot of different hardware configurations out there. These days, hardware is outdated by the time it is released. And the maintainers/volunteers/professionals are trying to juggle all those hardware configurations while simultaneously trying to limit the impact of bugs as much as possible.
Your PDP kernel. How many lines of code was it? Again, the Linux kernel is roughly 16 million (!) lines of code. Bugs are by nature inevitable. I’m willing to bet you did have bugs in your PDP kernel. It’s not your fault, not trying to diss you or anything. You’re human, you’re a flawed being. Heck, even the compilers and the languages those compilers compile are flawed to some extent or another.
And then, yes, you have a point – dependencies are an issue. But, be realistic here… it’s 2017. Not the 1970s. Back in the 70s, IT was either a hobby or a highly specialized tool. In this day and age, it’s common good. Heck, there are nations in this world that are moving towards elevating Internet access to the level of ‘basic needs’ (akin to, say, shelter, food, clean water). And that’s both inevitable and just. When was the last time you actually had to send a job application by post? Can’t do that anymore, you’re not going to be taken seriously. You cannot simply just do it all yourself anymore. That way, development time would explode to beyond the lifetime of a single individual human being, on larger projects.
Sorry, i just can’t agree on most of that. It’s overcomplicated as hell these days and imo it doesn’t need to be. I figure the code for my interactive debugger and window manager was maybe 300kloc of assembler. The only truly large project i ever worked on was 150-200 developers and i was one of a couple dozen tech writers that time; I don’t know how many loc it was but it was far too many imo. Never did like DB2, or SQL either, two-dimensional tables just don’t ring my chimes.
Anyway, if you wish, please continue giving up because it’s all just too hard (which is what it sounds like to me, sorry). I’ll just go off and write my own operating system and applications, it’s all in what you do first and how you do it. Of course it’ll all run on top of linux, until it’s burned into firmware, but i don’t mind cheating if that’s what it takes to get the job done.
I do understand, and all the points you make are valid, but the way i see it, when you’re starting out with erroneous assumptions and building a castle from them, it gets iffier, the higher it goes. fwiw.
[quote=“crankypuss, post:10, topic:13695”]please continue giving up because it’s all just too hard[/quote]… Excuse me?
- I did not deserve that semi-personal attack, I made no such personal attack on your person. I clearly stated – not trying to diss you. I was merely making an objective statement about the fallability of mankind. Any arrogance on your part that made more of that than I meant is not my responsibility.
- I never said anything about giving up. Apparently the point I was trying to make did not come across clearly. I’m going to assume responsibility there but I am unsure as how to proceed from there, how to clarify what I did mean as opposed to how you interpreted it.
- What ‘erroneous assumptions’ did I make or imply?
Anyhow, this has gone way beyond the scope of moving the log out button and I’m not at all sure I even want a reply but if you want to give one, just drop it in my messages. To prevent further derailing what initially was a suggestion.
1 Like
Apologies for having sounded as though i was attacking you, but isn’t that what you said, basically? There are 16 million loc in the linux kernel so we can’t fix things that are broken. My bad apparently…
As for the “erroneous assumptions” it’s the industry that’s made erroneous assumptions for a long time. Things like, addresses are actually necessary. Ideas like sharing installed code between users. We’re living in a thin-client world and trying to do it with an OS built to run on a mainframe/multi-user paradigm called Unix. Sometime get a really slow drive and install any linux distro on it; then watch the blinky-light as firefox loads dozens of libraries and so does everything else.
I suggested an improvement, and pointed out something that has been occurring in the industry since about the time “structured programming” was introduced, and corporate management decided it would be expedient if all programmers were interchangeable commodities, seeing as how grads were pouring out of colleges in the '80s and piling up those student debts.
Apologies for suggesting an improvement.
Apologies for pointing out how much energy is wasted by administrivia.
I’ll work a lot harder on not generating notifications, maybe that will help.
We can conclude the log out button is staying.
For me to possibly move the button would be some sort of JavaScript hack, and I do not have access to the server to modify the source code for Discourse. Plus, it’ll make maintenance for updates more difficult (I’m sure @Wimpy would agree on that one)
An alternate is to suggest this on Discourse Meta, and justify the change so all Discourse-powered forums will benefit, not just ours.
1 Like