On 18 October 2010 21:30, Henning Thielemann wrote:

Also it seems that 'tool building' is written lower case and thus at the last position at http://www.haskellers.com/skills/. What does 'tool building' mean?

Production of two-handed use langes Schwerts with long flambard blades and heavily category-theoretically decorated guards, katzbalgers, axes, mail and Macedonian quality defence pikes. Lambda Knights need to be prepared for the inevitable battle against success.

On Mon, 18 Oct 2010 22:03:15 +0200, wrote:

OK, I'm trying to install Haskore and it depends on an old version of QuickCheck. I'm happy to hack and update, but is there any way of finding out which modules depend on QuickCheck rather than going through each file one by one? The build-depends is right in the cabal file, where it should be; however, I don't know who puts it there when the cabal package was built. Is there any way to find out?

Select a version at: http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/package/QuickCh... and click the link directly after "Reverse deps." Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html --

On Mon, Oct 18, 2010 at 3:34 PM, Michael Snoyman wrote:

On Mon, Oct 18, 2010 at 8:47 PM, Daniel Peebles wrote:

...

Hi all, Might it be worthwhile to take the elected "superusers" on haskellers.com and let them police the skills list? It's become rather messy, with overly broad terms like "Mathematics" in it, as well as overly specific ones like "Other languages I know: C# .NET, XSLT, Microsoft SQL Server, XML, SQL, CSS, C, C++, Java, HTML, Visual Basic Script, Pascal, Rexx, Basic and assembler".

I concur that we need to switch the skills list to moderated. My plan is to lock out the ability to add skills by non-admins, then do a manual cleanup myself. After that, if you want a skill added to the list, you'll need to ask an admin to do it (there will be an automated request form, just like with verified user status).

Why don't you simply display only the most-used skills in the overview or listing of all skills? That way it isn't a manual process.

Just so everyone knows what it means to be an "admin": admin powers are very limited, it's basically a glorified moderator. That means that admins don't have the power to change your profile or anything like that. Except for me, what with having database write permissions, but that's kind of unavoidable ;).

So in general, I think I'm going to have to take out all of those overly-general and overly-specific ones, and clarify some of the others. Such as explaining what tool building is (thanks, Chris!).

Michael

PS: I can't believe no one added a "Write a monad tutorial" skill. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Mon, Oct 18, 2010 at 4:08 PM, Michael Snoyman wrote:

On Mon, Oct 18, 2010 at 11:01 PM, Antoine Latter wrote:

...

On Mon, Oct 18, 2010 at 3:34 PM, Michael Snoyman wrote:

...

On Mon, Oct 18, 2010 at 8:47 PM, Daniel Peebles wrote:

...

Hi all, Might it be worthwhile to take the elected "superusers" on haskellers.com and let them police the skills list? It's become rather messy, with overly broad terms like "Mathematics" in it, as well as overly specific ones like "Other languages I know: C# .NET, XSLT, Microsoft SQL Server, XML, SQL, CSS, C, C++, Java, HTML, Visual Basic Script, Pascal, Rexx, Basic and assembler".

I concur that we need to switch the skills list to moderated. My plan is to lock out the ability to add skills by non-admins, then do a manual cleanup myself. After that, if you want a skill added to the list, you'll need to ask an admin to do it (there will be an automated request form, just like with verified user status).

Why don't you simply display only the most-used skills in the overview or listing of all skills?

That way it isn't a manual process.

I already do, but look at how many people have selected "tool building" and "Mathematics" (myself included). Once the skill is in the list, people *will* choose it so they don't look like they don't know how to do something.

Maybe you could not offer suggestions on the "Edit your profile page"? Then the list of frequent tags would only show up on a search or drill-down page. Antione

On 18/10/2010 09:59 PM, Magnus Therning wrote:

On 18/10/10 21:56, Andrew Coppin wrote:

...

...I thought *I* was the only person who's ever heard of Rexx? Every amiga user is very likely to have heard of rexx, as a close relative to it was included in AmigaOS at some point.

...and I had of course assumed that I was the only person to have ever heard of the Amiga too. (Not that I suppose it matters 10 years later...)

On Mon, 18 Oct 2010, Andrew Coppin wrote:

On 18/10/2010 07:47 PM, Daniel Peebles wrote: Hi all, Might it be worthwhile to take the elected "superusers" on haskellers.com and let them police the skills list? It's become rather messy, with overly broad terms like "Mathematics" in it, as well as overly specific ones like "Other languages I know: C# .NET, XSLT, Microsoft SQL Server, XML, SQL, CSS, C, C++, Java, HTML, Visual Basic Script, Pascal, Rexx, Basic and assembler".

...I thought *I* was the only person who's ever heard of Rexx?

I even know ARexx! ;-)

On Tue, Oct 19, 2010 at 2:32 PM, Michael Snoyman wrote:

Algorithmic Problem Solving

I think this needs to go, because I'm really having a hard time imagining any programmer who doesn't do this.

High Assurance Software Development

This sounds vague to me and/or the same as other skills (cf. Formal Verification). Again, I'm not sure how many people would describe their software as "low assurance".

Robotics and Automation

Would be tempted to drop "Automation" from here.

Web development (HTML, CSS and Javascript)

I wonder if these parentheses are necessary, or if they hint at the fact that this isn't really one skill. I have a suspicion that being competent at website and stylesheet *design* (i.e. knowledge of good design principles and application to HTML/CSS) is an entirely different sort of thing from *implementation* in terms of JavaScript technologies like AJAX and JSON and who-knows-what. Overall, I think it would be nice to have a consistent idea about how concrete or abstract we allow skills to be, and as someone else mentioned what the target audience is for them. We have skills that relate to specific libraries and then skills that are nebulous and abstract. Maybe we could ask a narrower question, or have two fields: "what can you use", and "what interests you".

I just want to throw out 2 extreme case solutions to think about while this problem doesn't really seem to be heading anywhere: 1) Drop the skills options in favor of the simple text box already in use. This would of course would have a big impact on attempting to search for haskellers. 2) A formal Haskell certification system that would be of great use outside of haskellers.com too and recognized and trusted by employers all over the world. Java developers can certifiably in individual areas through thishttp://en.wikipedia.org/wiki/Sun_Certified_Professionalfor example.

In case anyway was worried, I *have* been following this thread, and purposely not sticking my nose in to see what people's opinions are. I've really appreciated the discussion; let me give my overall response to everything: It's good to remember that a user can always add whatever information they want to their self-description. The main reason for the skills list is so that employers and anyone else seeking Haskellers can easily get a list of people. As such, the skills should be something informative that people really want to search for. I'm pretty convinced that Mathematics as-is is a bad idea. I can't imagine *anyone* saying "I want a Haskeller who knows math" (maths for you Brits), it just doesn't say anything. We also need to make things much more explicit. "Cabal, packaging, build and distribution tools" really doesn't explain whether it means I can tweak Cabal, or if I can write a cabal file, or if I can build something that's on Hackage. The breakdown John Lato gave ("Cabal internals" and "Software packaging/distribution tools") sounds good to me. On this one you may call be biased, but I think keeping Happstack and Yesod on their own makes perfect sense. If I were an employer looking to hire someone to work on a project, I would be looking to see that they can use my tool of choice. Obviously we need to draw a line somewhere; putting up that you can use the failure package seems silly (I'm purposely picking on one of my own packages). But the web frameworks are entire ecosystems of their own, and I think it makes sense to keep them as-is. The issue of having to judge something in which I'm not an expert is definitely true. I don't have any experience with Attribute Grammar, for instance, and so feel ill-equipped to make a judgement on that. I'll trust the list on this, which seems to indicate leaving it in. I'll probably need to ask similar questions in the future. I also like the idea of dropping skills that everyone has. Algorithmic Problem Solving may very well fit in that category. Finally, the idea of a certification process is great. But I'm not going to do it ;). If I don't hear any major complaining in the next few hours, I'll implement what I've said above. Michael

OK, after reviewing the list again, here's some more that are on the chopping block, given the new outlook we've been establishing here. Speak up if you want it saved: Denotational design Programming using Arrows Transactional business applications development Categorical Programming On Thu, Oct 21, 2010 at 7:16 PM, Michael Snoyman wrote:

In case anyway was worried, I *have* been following this thread, and purposely not sticking my nose in to see what people's opinions are. I've really appreciated the discussion; let me give my overall response to everything:

It's good to remember that a user can always add whatever information they want to their self-description. The main reason for the skills list is so that employers and anyone else seeking Haskellers can easily get a list of people. As such, the skills should be something informative that people really want to search for.

I'm pretty convinced that Mathematics as-is is a bad idea. I can't imagine *anyone* saying "I want a Haskeller who knows math" (maths for you Brits), it just doesn't say anything.

We also need to make things much more explicit. "Cabal, packaging, build and distribution tools" really doesn't explain whether it means I can tweak Cabal, or if I can write a cabal file, or if I can build something that's on Hackage. The breakdown John Lato gave ("Cabal internals" and "Software packaging/distribution tools") sounds good to me.

On this one you may call be biased, but I think keeping Happstack and Yesod on their own makes perfect sense. If I were an employer looking to hire someone to work on a project, I would be looking to see that they can use my tool of choice. Obviously we need to draw a line somewhere; putting up that you can use the failure package seems silly (I'm purposely picking on one of my own packages). But the web frameworks are entire ecosystems of their own, and I think it makes sense to keep them as-is.

The issue of having to judge something in which I'm not an expert is definitely true. I don't have any experience with Attribute Grammar, for instance, and so feel ill-equipped to make a judgement on that. I'll trust the list on this, which seems to indicate leaving it in. I'll probably need to ask similar questions in the future.

I also like the idea of dropping skills that everyone has. Algorithmic Problem Solving may very well fit in that category.

Finally, the idea of a certification process is great. But I'm not going to do it ;).

If I don't hear any major complaining in the next few hours, I'll implement what I've said above.

Michael