Issue 132 in xmonad: We should have a convention for layout names

Issue 132: We should have a convention for layout names http://code.google.com/p/xmonad/issues/detail?id=132 Comment #1 by dons00: ' isn't very useful to non-Haskellers, but more regularity seems desirable. So, add some text to the STYLE guide if you've something concrete to do here -- no need to open a ticket for it. Issue attribute updates: Status: Invalid -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

On Fri, Feb 01, 2008 at 05:41:15PM -0800, codesite-noreply@google.com wrote:
Comment #1 by dons00: ' isn't very useful to non-Haskellers, but more regularity seems desirable.
So, add some text to the STYLE guide if you've something concrete to do here -- no need to open a ticket for it.
I'm sorry, I thought that a track system was for keeping track of the activities that can must be done, and a place where a discussion on how those activities must be done can take place, while a darcs push, which passes over the head of everybody, is just an unnoticed authoritative decision. But I will use it only in response to reports from other, starting from now. Thanks for the information. Andrea

Folks, it's clear we have some communication problems going on. Let's all step back and take a deep breath, hm? As seen from my vantage point (which is almost certainly inaccurate because I don't have access to your internal state --- then again, that's kind of the point...): Andrea has been playing with a new layout and decoration framework to address some shortcomings in xmonad. It seemed to me that he was sending patches to the list that he didn't expect to have committed (and at least one of them made me say "wait, I thought he said this was for experimentation, not committing"), and committing it probably left *him* feeling "committed". Since then has been a series of miscommunications because Don and Spencer seem to be looking at it from "Andrea is pushing incompletely-thought-out patches" and Andrea seems to be looking at it as "wait, my experimental patches got committed, now I have no choice but to figure out how to make them work". Can you three sit down (virtually, at least) and make sure you're all on the same page? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

allbery:
Folks, it's clear we have some communication problems going on. Let's all step back and take a deep breath, hm?
As seen from my vantage point (which is almost certainly inaccurate because I don't have access to your internal state --- then again, that's kind of the point...): Andrea has been playing with a new layout and decoration framework to address some shortcomings in xmonad. It seemed to me that he was sending patches to the list that he didn't expect to have committed (and at least one of them made me say "wait, I thought he said this was for experimentation, not committing"), and committing it probably left *him* feeling "committed". Since then has been a series of miscommunications because Don and Spencer seem to be looking at it from "Andrea is pushing incompletely-thought-out patches" and Andrea seems to be looking at it as "wait, my experimental patches got committed, now I have no choice but to figure out how to make them work".
Can you three sit down (virtually, at least) and make sure you're all on the same page?
Thanks for faciliting this Brandon. My concern is: * too much traffic is going to the list * experiments that should just be passed around on IRC are going to the list when they shouldn't * there are unclear expectations of the role Spencer and I play supervising code. One concrete suggestion would be to sit on patches for longer, Andrea. That is, code them up, then experiment for a few days until you're sure everything's ok. Only then send things to the list. That way you avoid overwhelming people with the streams of patches that appear. Consider how many people actually need to know about the problem. Do all xmonad subscribers need to know? A second point: not everyone will be interested in all the things you work on. After all, it is open source, so you do as you please. Just don't expect to always get feedback on your experiments -- and you shouldn't be upset if people aren't interested. -- Don

On Feb 1, 2008, at 21:19 , Don Stewart wrote:
That way you avoid overwhelming people with the streams of patches that appear. Consider how many people actually need to know about the problem. Do all xmonad subscribers need to know?
Most active projects have separate -users and -devel lists. I have myself thought that xmonad was active enough that keeping them combined was likely to annoy both users (who don't want to see, or care about, most of these patches) and developers (who are likely to regard user-type questions/discussions as unnecessary distractions). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

* Brandon S. Allbery KF8NH
On Feb 1, 2008, at 21:19 , Don Stewart wrote:
That way you avoid overwhelming people with the streams of patches that appear. Consider how many people actually need to know about the problem. Do all xmonad subscribers need to know?
Most active projects have separate -users and -devel lists. I have myself thought that xmonad was active enough that keeping them combined was likely to annoy both users (who don't want to see, or care about, most of these patches) and developers (who are likely to regard user-type questions/discussions as unnecessary distractions).
I am against this separation. One thing I really love about xmonad (project, not WM itself) is low threshold between users and developers. I think most users are interested in what happens here (new features and extensions, etc), and if developers do not read -users list (not to get distracted) who will answer users' questions? -- Roman I. Cheplyaka (aka Feuerbach @ IRC)

roma:
* Brandon S. Allbery KF8NH
[2008-02-01 21:24:46-0500] On Feb 1, 2008, at 21:19 , Don Stewart wrote:
That way you avoid overwhelming people with the streams of patches that appear. Consider how many people actually need to know about the problem. Do all xmonad subscribers need to know?
Most active projects have separate -users and -devel lists. I have myself thought that xmonad was active enough that keeping them combined was likely to annoy both users (who don't want to see, or care about, most of these patches) and developers (who are likely to regard user-type questions/discussions as unnecessary distractions).
I am against this separation. One thing I really love about xmonad (project, not WM itself) is low threshold between users and developers.
I think most users are interested in what happens here (new features and extensions, etc), and if developers do not read -users list (not to get distracted) who will answer users' questions?
I agree. There won't be a split. We have a long term goal of training up new users as developers too, and the mailing list servers this function. -- Don

mailing_list:
On Fri, Feb 01, 2008 at 05:41:15PM -0800, codesite-noreply@google.com wrote:
Comment #1 by dons00: ' isn't very useful to non-Haskellers, but more regularity seems desirable.
So, add some text to the STYLE guide if you've something concrete to do here -- no need to open a ticket for it.
I'm sorry, I thought that a track system was for keeping track of the activities that can must be done, and a place where a discussion on how those activities must be done can take place, while a darcs push, which passes over the head of everybody, is just an unnoticed authoritative decision.
But I will use it only in response to reports from other, starting from now.
Its useful for bugs that need to be fixed. And things we need to remember to do. If its just a style thing, we can put that in the style guide. But its a good idea not to pollute the bug tracker with too many idle things, since we won't be able to manage so many open tickets -- they'll just get closed.
participants (5)
-
Andrea Rossato
-
Brandon S. Allbery KF8NH
-
codesite-noreply@google.com
-
Don Stewart
-
Roman Cheplyaka