Encourage IRC participation via "Chat with the maintainers" or somesuch #1235
Comments
|
A better freenode link is in fact: https://webchat.freenode.net/?randomnick=1&prompt=1&channels=#perl |
|
Never used it but... https://scrollback.io/perl/ might be worth checking out perlorg/perlweb#106 for example used it |
|
I need to look further at scrollback.io. However, one of the upsides of mibbit is that the user's hostmask contains enough information for kickbans and klines to work without affecting others inappropriately. Their user info also carries their real hostmask should we need to report abuse. |
|
@ranguard I couldn't find the logging settings (and discussion thereof) of scrollback.io. In general many channels (including the lair I hail from namely #dbix-class) have a very strict no-public-logs policy for a very good reason. Could someone with more knowledge elaborate? |
|
@aravindet would you care to comment on this? |
|
@ranguard thanks! A greatly improved release of Scrollback is scheduled to be launched this week, (you can preview it on the staging server at next.scrollback.io; "development" branch on github) so I will answer your questions with respect to the features in that. @ribasushi A channel operator's consent is needed to add a channel to a Scrollback room. Someone with a chanop flag must /msg our bot before it joins the channel. (It will be on the network). You can't use Scrollback as an IRC client without logging the channel, sorry. You can, however, prevent search engines from indexing the logs. If at any point you want to delete them, you can do that too. (Right now you'll have to email me, but we'll get around to making a web interface for this sometime.) @sungo We use pretty much the same mechanisms as Mibbit to ensure that IRC networks can kickban/kline individual Scrollback users without affecting the entire server. Freenode's recommended way is to run an ident daemon that reports the user's IP address when queried; Some other networks need us to send a nonstandard "WEBIRC" command with the user's IP while connecting. We support both, and I believe it's the same with Mibbit, KiwiIRC etc. |
|
@aravindet the logging bit is a problem for irc.perl.org. we have a strict 'no public logging without published consent' policy. In order for any non-personal logging to happen, the channel needs to publish that policy, typically in the topic, so all joining users know they're being publicly logged. Having their channels logged by a third-party service without their individual knowledge and consent has always had a chilling affect on our user base. We should talk about it somewhere other than this ticket though. Also, when you say "chanop flag", do you mean anyone who is +o in the channel or are you relying on the network having some services package to provide that information? |
|
From the sound of things, scrollback.io is not going to be welcome on irc.perl.org and mibbit is banned on freenode. Picking one or the other is also going to cause problems for our users one way or the other. It also puts us in the position of recommending one company/startup over another. There might be an easier option here. The irc:// protocol prefix in the browser can be used to trigger whatever app the user has set as default for it. Then the user can choose which client they want. Maybe add an FAQ entry about it and point to several options. This is documented to work in FF, at least. The url that @ribasushi mentions in the original issue could be inlined in a standard href. |
This should work around the issue of 'preferred company/startup' raised in metacpan/metacpan-web#1235 (comment)
|
@sungo Having metacpan-wide endorsement of a particular webchat applet would indeed be problematic. How about a new maintainer-mandated weblink as in Perl5/DBIx-Class@a89c6a79e0. We already do the same in our POD anyway, so it isn't feature-creep: https://metacpan.org/pod/DBIx::Class#HOW-TO-GET-HELP @ranguard thoughts on the above? |
|
It might make sense to have it match up with repository handling, with |
|
@haarg +1 |
|
I've written up a patch to include this at https://github.com/haarg/metacpan-web/tree/irc-display. It's currently built on top of PR #1281, so I'm going to wait on that before trying to get it merged. It supports both x_IRC with url and web sub-keys, as well as x_IRC and x_WebIRC as separate links. If a web link isn't available, it will try to construct one for you, using freenode's webchat on that network and mibbit for anywhere else. |
|
While the progress on the implementation side of things is AWESOME, the visual implementation is lacking. Take for example https://metacpan.org/release/RIBASUSHI/DBIx-Class-0.082700_06. The "chat with maints" link is buried down on the left. My original idea for this ticket was Imagine just how engaging it is to go read oddball docs, and be reminded at all times "Yes, if you don't get it - click here and ask". I am adding several more folks to the thread who are much better at articulating this than I am: @wchristian, @xsawyerx, @ranguard, @monken please chime in ;) |
|
I agree with the idea and the sentiment. Perl needs to improve its outreach to "disconnected" members as much as it possibly can. That said, metacpan is beginning to look a little cluttered. I think it might be valuable to split the side section up a bit. An idea for a split would be:
With proper icons, changes due to presence or absence of metadata would draw attention. Maybe this should be a different ticket though. |
|
@wchristian I agree about the general "cluttered" issue. However I want to unambiguously reiterate: I think IRC deserves an exception form this (and a promotion to a higher level visibility). In my world "Talk to us" is so so so so much more important than say "fork this", or "contribute". We already have tons of shitty code, promoting people to write more shitty code in the dark, as opposed to promoting communication is the main issue OSS has these days (@rehsack would have a long rant to add to that :) So yes, while "decluter metacpan" is a good idea in itself, please let's not lose sight of the fact that MetaCPAN has an excellent chance to do communication right. |
|
@wchristian I realize I did not address your main point of (seeming) confusion. IRC is 2-way engaging, instant-feedback communication. Everything else (bugs, ratings etc) is a one-way, fire-and-forget style of engagement. I want to turn the clock towards more of the former - a lively conversation (governed by cooler heads these days, say hi to the SRB) is much more likely to involve new members (and keep them around). |
|
Yeah, i didn't express my thoughts clearly there: I was thinking that if there's a clear "use these to talk to us" section, they could be ordered by importance, with IRC on top. |
|
After catching up with riba on IRC, i have this to say: I completely agree with him, and think that for dists with irc metadata it should be painfully obvious to everyone that having a view-follow ribbon on all the pages of a dist, and especially the ones commonly linked to when discussing a dist, provides such a large amount of value that it should not only be a highly considered option, but in fact a requirement. |
|
I like the idea of ribbon on the top right corner, but another ribbon on the left for 'Chat with maintainers' is a bit too much IMO. I will also figure out or any one have any better idea ? |
|
@oiami Note that there is relatively wide consensus that the "github"-pointing ribbon is much less important than the Thanks for picking this issue up! :) |
|
@ribasushi and everyone, how about the small icon instead of ribbon like this |
|
That would be a very very minor unnoticeable change on the already overloaded link-field. While in itself it doesn't look bad (it's even cute), I think it entirely misses the point. Perhaps we need to make sure we are all on the same page: my main goal here is to make metacpan SCREAM that there is a chat option available. Anything less than that is a waste of pixels (agsain, in my opinion). Can we get a quick poll of all watchers on the ticket? If I am the only one who feels the chat option needs to be visually forced - I will concede the issue and move on to something else ;) |
|
If you want to SCREAM how about this ? Too much ? lol |
|
It really depends on context. But I really think the "what metacpan devs want to see" should be framed better. AFAIK @haarg had reservations about promoting the link, perhaps he is not the only one. Let's figure out what we want the impact to be, then it will be quite obvious what the link should be styled like. |
|
So, 90 dists have x_irc... http://grep.cpan.me/?q=file%3AMETA.json+%28%3Fi%3Ax_irc%29 146 have x_mail... http://grep.cpan.me/?q=file%3AMETA.json+%28%3Fi%3Ax_mail%29 I think there is a balance, yes we want it easy to find, but maybe not I'm afraid I've not been following closely, but there was discussion of
Just brain dumping here, don't feel strongly |
|
If I define x_irc and x_mail, is there a way for me to indicate which I prefer? I've worked on several projects which had both irc and mailing lists but "official" conversation needed to happen on the list. It would be unfortunate to have metacpan scream about the wrong one. I think the middle ground might be to have metacpan scream equally about the various communication types. That said, I think the communication links need to be more visible than @oiami's screencap. I lack the design fu at the moment to provide an example screencap but I think perhaps those links should be boxed on their own and more obviously highlighted. I think the same thing about the testing links too but that's something for a different ticket :) |
|
I'd say start with the ribbon and the see what the fallout is. We can A/B test from that point. |
|
Yes, pleas. @oiami 's ribbon suggestion there looks perfect, and until we know whether that will bring villagers with pitchforks or not, most of the other topics are distractions, and i dare say should be in different tickets. :) |
|
JFDI++ |
|
A practical nitpick - I think proper English is |
|
That may be better for places where the maintainers don't use the IRC as much, but there is a channel for general discussion. That may actually be the exception to the rule. |
|
Bleh, UX is hard. It was pointed on irc that all the wordings so far can be interpreted as "Click here for help with this website (metacpan)". I suppose for complete disambiguity the ribbon should read: OTOH real estate may be an issue... |
|
If that's the route we go down, I'd suggest "Questions about this module?" rather than inserting the module name. The POE namespace, amongst others, make inserting the module name really problematic, space wise. |
|
Fwiw the actual CSS-styled-ribbon generator from github can be used here with minimal fuss: http://codepo8.github.io/css-fork-on-github-ribbon/ @Mithaldu++ |
|
@sungo You are correct, Sir. This module would also be a problem: https://metacpan.org/release/Acme-Working-Out-Dependencies-From-META-files-Will-Be-Wrong-At-Some-Point-Like-This-Module-For-Instance |
|
Soooo what is the holdup on this thing? Seems to have fizzled :( |
oalders
changed the title
|
Who is taking on the the design work here? Is it @oiami? |
|
@oalders , I guess so ;) sorry that it takes sometime, I was busy + waited for more feedback and conclusion about the things I proposed, I'll try to send a pull request soon. |
|
@oiami No need to apologize. Just wanted to make sure. :) |
|
This is the first version of "Chat with maintainers" ribbon Do you have some kind of conclusion about what the text should be ? I personally like 'Chat with maintainers' or "Chat with the maintainers" because it not too long so it fits with layout and I think 'chat' is discriptive and cover what we trying tell because they can contract you with many reasons more than 'asking question', don't you think so ? |
|
Visually - it looks great, however it would need to be positioned so that it will keep being visible after scrolling within the POD. The rationale is (like @wchristian said in #1235 (comment)) that when you are linked to a piece of POD on metacpan you want to be reminded that "if you don't get it - come to talk to others who can help" As far as the text - @zmughal made a very good point in #1235 (comment) - the link won't neccessarily take one to talk to the maintainers. With that in mind the |
|
Also forgot: |
|
more ribbons on the top right (Fork me on GitHub), any comment about (color, text, size etc) that ?
FYI, I can do front-end stuffs but I'm also poor at design, hehe ;) |
|
The left sidebar already stays visible when scrolling, so I think the current location works fine. @oiami: I can reproduce what you showed most recently using CSS (haarg/metacpan-web@6a51c26). I think I'd prefer to use that rather than an image. |
|
I'd rather address any additional ribbons separately. There are issues of priority, and positioning is hard given we are already using the upper right for something. It's also somewhat confusing to overlay part of the site wrapper, as that implies it relates to metacpan itself rather than the release/module. |
|
👍 on "let's deal with more ribbons later on". As @haarg noted - priority is important (and I personally disagree making forking more visible and/or different from the chat-with-us part, reasons already outlined earlier in #1235 (comment)) So yes - let's get the chat-link link live first, and see from there. |
|
@haarg , are you going to send a pull request for ribbon from CSS you have made ? |
|
I don't have any further comments on the proposal from #1348. Let's put that thing live ;) |
While discussing http://www.irc.perl.org/governance.html with @sungo and @perigrin during this past YAPC::NA the following idea materialized: for any project which lists an irc resource it would be quite handy to render a very visible button on all metacpan pages which redirects to an instant web-chat page.
For instance for DBIx::Class' https://metacpan.org/source/RIBASUSHI/DBIx-Class-0.08270/META.yml#L64
irc://irc.perl.org/#dbix-classthe corresponding link would behttps://chat.mibbit.com/#[email protected]
Things to keep in mind:
http://grep.cpan.me/?q=file%3AMETA.yml+%5E%5Cs%7B0%2C30%7D%22%3F%28%3Fi%3A.%7B0%2C5%7D%3Firc%29%22%3F%5Cs%3F%5C%3A
The text was updated successfully, but these errors were encountered: