Re: radical proposal: move IRC to Rocket.Chat
While I generally agree with your feeling that the feeling for IRC was a bit negative, I disagree here: Il 10 agosto 2017 22:34:19 EEST, Christian Loosli ha scritto: > >If people want to switch themselves: already possible, with or without >this >thread and the etherpad. > >The original topic of this thread is _move_ to rocket, and the title of >the >etherpad is to find an IM that suits people best. So either you want to > >switch, then the cornerns of the people mentioned are fully valid, or >you >don't, then you already have everything and the whole thing is >pointless The topic is what it is because of how it started but the etherpad is still useful. Even if more bridges are available, maybe it is possible to choose one of them as primary or preferred, where invest in terms of client or support on the server side or whatever. Ciao -- Luigi
Re: radical proposal: move IRC to Rocket.Chat
Il 10 agosto 2017 22:22:04 EEST, Thomas Pfeiffer ha scritto: >On Donnerstag, 10. August 2017 20:38:11 CEST Christian Loosli wrote: >> Am Donnerstag, 10. August 2017, 20:31:22 CEST schrieb Thomas >Pfeiffer: >> > On Donnerstag, 10. August 2017 18:40:34 CEST Christian Loosli >wrote: >> > > Am Donnerstag, 10. August 2017, 17:25:14 CEST schrieb Jonathan >Riddell: >> > > > LibreOffice are having a similar discussion >> > > > >> > > > >https://listarchives.libreoffice.org/global/projects/msg02257.html >> > > > >> > > > They want to continue using IRC though which means >fragmentation would >> > > > continue. >> > > >> > > Maybe someone should inform them that there are bridges available >to >> > > avoid >> > > that. >> > > >> > > But maybe they'd simply ignore that, multiple times, and go on, >as some >> > > people seem to do in this thread as well *shrug* >> > >> > Who ignored the possibility of bridges? >> >> Why are we still discussing, then? As I pointed out twice: bridges >not only >> exist, but they are already in place. So unless people want to get >rid of >> IRC (or one of the other protocols, for that), it is pointless to >discuss >> which client/protocol to take, since it already either is bridged or >not >> bridgeable yet, but soon to be. >> And then the answer is clearly "IRC plus bridge", and both this >whole >> thread and the etherpad can be abandoned. > >Erm... no. IRC is a "legacy option" for people who don't want to use >other >protocols for whatever reason. That is perfectly fine for them, that's >why >we're keeping it. > >However, if the people who _do_ want to use something more modern end >up using >10 different things, then the benefits are practically non-existent. >Most of >the nice features of modern protocols work only among those who use the >same >one. > >Therefore, to get any benefit, we, the people who want something >modern, have >to agree on one thing. You, the old-school IRC lovers, can feel free to > >completely ignore us while we search for something that checks all our >requirements, we bridge it to IRC, everybody is happy. >Does that sound like a plan? I'm glad that this is the idea. But let me point out that in your original proposalof requirements: https://mail.kde.org/pipermail/kde-community/2017q3/003693.html the bridges are in the section "Nice-to-haves" and not "Must-have". I also find the description a bit too much on the negative side: "For the transitional period or for people who just refuse to change their habits" This is one of the reasons why there seems to be a "ditch IRC" idea. Happy to hear that it's not the general feeling. Also: > >I, for one, did not chime into this discussion because I wanted to get >rid of >IRC. I chimed in because I got the impression from some of the replies >that >there would be no need to use anything other than IRC, because it has >everything we need. >I still strongly disagree with that. My impression is that everyone who advocated for IRC is saying: as long as it is bridged and functional I don't care about what other technologies can be used to access it, while I may disagree on the definition of obsolete. -- Luigi
Re: I cannot login into the Community Wiki
Hey Alberto, On Thu, Aug 10, 2017 at 3:27 PM, Alberto Salvia Novella < es204904...@gmail.com> wrote: > I have created a Phabricator account, and now I'm able to login into: > - (https://phabricator.kde.org) > - (https://identity.kde.org) > - (https://techbase.kde.org) > > But not into: > - (https://community.kde.org) > > Any idea how could I make it work? Thanks in advance š > If you are on IRC, I suggest visiting the #kde-sysadmin channel and asking there. If you are not, syaad...@kde.org will work too. Valorie -- http://about.me/valoriez
Re: I cannot login into the Community Wiki
Yep me here, I'm in the Kubuntu camp. On Aug 10, 2017 7:39 PM, "Alberto Salvia Novella" wrote: > Aaron Honeycutt: > >> Odd I just logged in fine. >> > > You here! Hahaha! > > Well, it seems I bricked the account somehow. > >
Re: I cannot login into the Community Wiki
Aaron Honeycutt: Odd I just logged in fine. You here! Hahaha! Well, it seems I bricked the account somehow. smime.p7s Description: S/MIME Cryptographic Signature
Re: I cannot login into the Community Wiki
Odd I just logged in fine. On Aug 10, 2017 6:27 PM, "Alberto Salvia Novella" wrote: > I have created a Phabricator account, and now I'm able to login into: > - (https://phabricator.kde.org) > - (https://identity.kde.org) > - (https://techbase.kde.org) > > But not into: > - (https://community.kde.org) > > Any idea how could I make it work? Thanks in advance š > >
I cannot login into the Community Wiki
I have created a Phabricator account, and now I'm able to login into: - (https://phabricator.kde.org) - (https://identity.kde.org) - (https://techbase.kde.org) But not into: - (https://community.kde.org) Any idea how could I make it work? Thanks in advance š smime.p7s Description: S/MIME Cryptographic Signature
Re: radical proposal: move IRC to Rocket.Chat
On August 11, 2017 4:22:04 AM GMT+09:00, Thomas Pfeiffer wrote: >On Donnerstag, 10. August 2017 20:38:11 CEST Christian Loosli wrote: >> Am Donnerstag, 10. August 2017, 20:31:22 CEST schrieb Thomas >Pfeiffer: >> > On Donnerstag, 10. August 2017 18:40:34 CEST Christian Loosli >wrote: >> > > Am Donnerstag, 10. August 2017, 17:25:14 CEST schrieb Jonathan >Riddell: >> > > > LibreOffice are having a similar discussion >> > > > >> > > > >https://listarchives.libreoffice.org/global/projects/msg02257.html >> > > > >> > > > They want to continue using IRC though which means >fragmentation would >> > > > continue. >> > > >> > > Maybe someone should inform them that there are bridges available >to >> > > avoid >> > > that. >> > > >> > > But maybe they'd simply ignore that, multiple times, and go on, >as some >> > > people seem to do in this thread as well *shrug* >> > >> > Who ignored the possibility of bridges? >> >> Why are we still discussing, then? As I pointed out twice: bridges >not only >> exist, but they are already in place. So unless people want to get >rid of >> IRC (or one of the other protocols, for that), it is pointless to >discuss >> which client/protocol to take, since it already either is bridged or >not >> bridgeable yet, but soon to be. >> And then the answer is clearly "IRC plus bridge", and both this >whole >> thread and the etherpad can be abandoned. > >Erm... no. IRC is a "legacy option" for people who don't want to use >other >protocols for whatever reason. That is perfectly fine for them, that's >why >we're keeping it. > >However, if the people who _do_ want to use something more modern end >up using >10 different things, then the benefits are practically non-existent. >Most of >the nice features of modern protocols work only among those who use the >same >one. > >Therefore, to get any benefit, we, the people who want something >modern, have >to agree on one thing. You, the old-school IRC lovers, can feel free to > >completely ignore us while we search for something that checks all our >requirements, we bridge it to IRC, everybody is happy. >Does that sound like a plan? > >> > Where does Martin Steigerwald's impression come from that people >want to >> > make this an "either/or decision"? >> > >> > The only person who seems to want to get rid of IRC is Jonathan, >> >> Okay, this is a qft moment. How can you possibly write "where does >$person >> impression come from that people want to make this an either/or >decision" >> when you write, at the very next line, that for someone, the thread >starter >> to be precise, it is? > >Jonathan Riddell. Singular. One guy. Not "people". > >> > I never said that. Martin Klapetek never said that. >> > Yes, we both think that IRC is not suitable as the _only_ chat tool >for a >> > community in 2017. >> >> I never pointed fingers at you. I said that some people seem to see >it as an >> either/or, which you agree with, and that people seem to ignore that >> bridges already exist and are in place (at KDE, not in general, >mind), so >> the logical conclusion is that, unless it becomes an either/or, this >whole >> thing is completely pointless. > >Again. Jonathan. One. >And he does not ignore bridges at all. To quote him from an email in >this very >thread: > >> Moving wholesale to something which has the advantages of IRC and the >> advantages of Telegram would avoid fragmentation that I see and it >> would avoid the faff of bridges which makes it even harder to follow >> who is who on each place. > >There they are. Bridges. Jonathan clearly acknowledges their existence, >but >considers them an impediment to the overall experience. >An opinion which he is perfectly entitled to, and which you won't >change just >by pointing something out to him that he already knows. > >> > Why do people feel something is threatened without people >threatening it? >> >> Next qft moment, how can you possibly write that, when above you >write that >> >> > The only person who seems to want to get rid of IRC is Jonathan, >> >> or how can you possibly call "getting rid of IRC" is not threatening >it? >> That is honestly beyond me. > >Simple explanation: How can the personal opinion of a single KDE >contributor >threaten anything? If whenever a single person in KDE dislikes >something I'd >feel its existence within KDE might be in danger, I'd spend my days in >a >corner shivering. > >I, for one, did not chime into this discussion because I wanted to get >rid of >IRC. I chimed in because I got the impression from some of the replies >that >there would be no need to use anything other than IRC, because it has >everything we need. >I still strongly disagree with that. I'm very much frustrated by the use of "protocols". Rocket.Chat for example is not a protocol. There's no spec for servers and clients to follow, no governance model for that spec, no stability guarantees. It's entirely implementation-defined. Which is meh. Of the contenders discuss
Re: radical proposal: move IRC to Rocket.Chat
Am Donnerstag, 10. August 2017, 21:22:04 CEST schrieb Thomas Pfeiffer: > On Donnerstag, 10. August 2017 20:38:11 CEST Christian Loosli wrote: > > Am Donnerstag, 10. August 2017, 20:31:22 CEST schrieb Thomas Pfeiffer: > > > On Donnerstag, 10. August 2017 18:40:34 CEST Christian Loosli wrote: > > > > Am Donnerstag, 10. August 2017, 17:25:14 CEST schrieb Jonathan Riddell: > > > > > LibreOffice are having a similar discussion > > > > > > > > > > https://listarchives.libreoffice.org/global/projects/msg02257.html > > > > > > > > > > They want to continue using IRC though which means fragmentation > > > > > would > > > > > continue. > > > > > > > > Maybe someone should inform them that there are bridges available to > > > > avoid > > > > that. > > > > > > > > But maybe they'd simply ignore that, multiple times, and go on, as > > > > some > > > > people seem to do in this thread as well *shrug* > > > > > > Who ignored the possibility of bridges? > > > > Why are we still discussing, then? As I pointed out twice: bridges not > > only > > exist, but they are already in place. So unless people want to get rid of > > IRC (or one of the other protocols, for that), it is pointless to discuss > > which client/protocol to take, since it already either is bridged or not > > bridgeable yet, but soon to be. > > And then the answer is clearly "IRC plus bridge", and both this whole > > thread and the etherpad can be abandoned. > > Erm... no. IRC is a "legacy option" for people who don't want to use other > protocols for whatever reason. That is perfectly fine for them, that's why > we're keeping it. > > However, if the people who _do_ want to use something more modern end up > using 10 different things, then the benefits are practically non-existent. > Most of the nice features of modern protocols work only among those who use > the same one. > > Therefore, to get any benefit, we, the people who want something modern, > have to agree on one thing. You, the old-school IRC lovers, can feel free > to completely ignore us while we search for something that checks all our > requirements, we bridge it to IRC, everybody is happy. Friendly reminder that - the protocols that are bridgeable are bridged and already usable - the people who want to switch to these already can - the people who don't want to already can. This is the status quo, thus saying that unless you plan to get rid of things or move things, the discussion is pointless, as it represents the status quo. > > > Where does Martin Steigerwald's impression come from that people want to > > > make this an "either/or decision"? > > > > > > The only person who seems to want to get rid of IRC is Jonathan, > > > > Okay, this is a qft moment. How can you possibly write "where does > > $person > > impression come from that people want to make this an either/or decision" > > when you write, at the very next line, that for someone, the thread > > starter > > to be precise, it is? > > Jonathan Riddell. Singular. One guy. Not "people". Not only that people is entirely allowed and correct in English, but also see above: unless you want to move / change, the debate is pointless, I assume that is why various people, not only me, got that impression. > > > I never said that. Martin Klapetek never said that. > > > Yes, we both think that IRC is not suitable as the _only_ chat tool for > > > a > > > community in 2017. > > > > I never pointed fingers at you. I said that some people seem to see it as > > an either/or, which you agree with, and that people seem to ignore that > > bridges already exist and are in place (at KDE, not in general, mind), > > so the logical conclusion is that, unless it becomes an either/or, this > > whole thing is completely pointless. > > Again. Jonathan. One. See above. > I, for one, did not chime into this discussion because I wanted to get rid > of IRC. I chimed in because I got the impression from some of the replies > that there would be no need to use anything other than IRC, because it has > everything we need. > I still strongly disagree with that. Nope, see above. People pointed out, various times by now, that IRC is the lowest common denominator and that the rest not only can be bridged, but is bridged. So people who want to move to any of these protocols already can, and there is no point to discuss benefits and disadvantages of the various protocols, since right now you can have any of them. So, once more: unless you want to get rid of one, this whole thing is pointless. If you, or a group, prefer Matrix: you can use that, right now, this very second. If you prefer Telegram: same. If people want to throw something fancy at 20 year olds who can't or don't want to handle IRC: already possible, with or without this thread and the etherpad. If people want to switch themselves: already possible, with or without this thread and the etherpad. The original topic of this thread is _move_ to rocket, and the
Re: radical proposal: move IRC to Rocket.Chat
On Donnerstag, 10. August 2017 20:38:11 CEST Christian Loosli wrote: > Am Donnerstag, 10. August 2017, 20:31:22 CEST schrieb Thomas Pfeiffer: > > On Donnerstag, 10. August 2017 18:40:34 CEST Christian Loosli wrote: > > > Am Donnerstag, 10. August 2017, 17:25:14 CEST schrieb Jonathan Riddell: > > > > LibreOffice are having a similar discussion > > > > > > > > https://listarchives.libreoffice.org/global/projects/msg02257.html > > > > > > > > They want to continue using IRC though which means fragmentation would > > > > continue. > > > > > > Maybe someone should inform them that there are bridges available to > > > avoid > > > that. > > > > > > But maybe they'd simply ignore that, multiple times, and go on, as some > > > people seem to do in this thread as well *shrug* > > > > Who ignored the possibility of bridges? > > Why are we still discussing, then? As I pointed out twice: bridges not only > exist, but they are already in place. So unless people want to get rid of > IRC (or one of the other protocols, for that), it is pointless to discuss > which client/protocol to take, since it already either is bridged or not > bridgeable yet, but soon to be. > And then the answer is clearly "IRC plus bridge", and both this whole > thread and the etherpad can be abandoned. Erm... no. IRC is a "legacy option" for people who don't want to use other protocols for whatever reason. That is perfectly fine for them, that's why we're keeping it. However, if the people who _do_ want to use something more modern end up using 10 different things, then the benefits are practically non-existent. Most of the nice features of modern protocols work only among those who use the same one. Therefore, to get any benefit, we, the people who want something modern, have to agree on one thing. You, the old-school IRC lovers, can feel free to completely ignore us while we search for something that checks all our requirements, we bridge it to IRC, everybody is happy. Does that sound like a plan? > > Where does Martin Steigerwald's impression come from that people want to > > make this an "either/or decision"? > > > > The only person who seems to want to get rid of IRC is Jonathan, > > Okay, this is a qft moment. How can you possibly write "where does $person > impression come from that people want to make this an either/or decision" > when you write, at the very next line, that for someone, the thread starter > to be precise, it is? Jonathan Riddell. Singular. One guy. Not "people". > > I never said that. Martin Klapetek never said that. > > Yes, we both think that IRC is not suitable as the _only_ chat tool for a > > community in 2017. > > I never pointed fingers at you. I said that some people seem to see it as an > either/or, which you agree with, and that people seem to ignore that > bridges already exist and are in place (at KDE, not in general, mind), so > the logical conclusion is that, unless it becomes an either/or, this whole > thing is completely pointless. Again. Jonathan. One. And he does not ignore bridges at all. To quote him from an email in this very thread: > Moving wholesale to something which has the advantages of IRC and the > advantages of Telegram would avoid fragmentation that I see and it > would avoid the faff of bridges which makes it even harder to follow > who is who on each place. There they are. Bridges. Jonathan clearly acknowledges their existence, but considers them an impediment to the overall experience. An opinion which he is perfectly entitled to, and which you won't change just by pointing something out to him that he already knows. > > Why do people feel something is threatened without people threatening it? > > Next qft moment, how can you possibly write that, when above you write that > > > The only person who seems to want to get rid of IRC is Jonathan, > > or how can you possibly call "getting rid of IRC" is not threatening it? > That is honestly beyond me. Simple explanation: How can the personal opinion of a single KDE contributor threaten anything? If whenever a single person in KDE dislikes something I'd feel its existence within KDE might be in danger, I'd spend my days in a corner shivering. I, for one, did not chime into this discussion because I wanted to get rid of IRC. I chimed in because I got the impression from some of the replies that there would be no need to use anything other than IRC, because it has everything we need. I still strongly disagree with that.
Re: radical proposal: move IRC to Rocket.Chat
Am Donnerstag, 10. August 2017, 20:31:22 CEST schrieb Thomas Pfeiffer: > On Donnerstag, 10. August 2017 18:40:34 CEST Christian Loosli wrote: > > Am Donnerstag, 10. August 2017, 17:25:14 CEST schrieb Jonathan Riddell: > > > LibreOffice are having a similar discussion > > > > > > https://listarchives.libreoffice.org/global/projects/msg02257.html > > > > > > They want to continue using IRC though which means fragmentation would > > > continue. > > > > Maybe someone should inform them that there are bridges available to avoid > > that. > > > > But maybe they'd simply ignore that, multiple times, and go on, as some > > people seem to do in this thread as well *shrug* > > Who ignored the possibility of bridges? Why are we still discussing, then? As I pointed out twice: bridges not only exist, but they are already in place. So unless people want to get rid of IRC (or one of the other protocols, for that), it is pointless to discuss which client/protocol to take, since it already either is bridged or not bridgeable yet, but soon to be. And then the answer is clearly "IRC plus bridge", and both this whole thread and the etherpad can be abandoned. > Where does Martin Steigerwald's impression come from that people want to > make this an "either/or decision"? > > The only person who seems to want to get rid of IRC is Jonathan, Okay, this is a qft moment. How can you possibly write "where does $person impression come from that people want to make this an either/or decision" when you write, at the very next line, that for someone, the thread starter to be precise, it is? > I never said that. Martin Klapetek never said that. > Yes, we both think that IRC is not suitable as the _only_ chat tool for a > community in 2017. I never pointed fingers at you. I said that some people seem to see it as an either/or, which you agree with, and that people seem to ignore that bridges already exist and are in place (at KDE, not in general, mind), so the logical conclusion is that, unless it becomes an either/or, this whole thing is completely pointless. > Why do people feel something is threatened without people threatening it? Next qft moment, how can you possibly write that, when above you write that > The only person who seems to want to get rid of IRC is Jonathan, or how can you possibly call "getting rid of IRC" is not threatening it? That is honestly beyond me. > Puzzled, > Thomas Same, Christian
Re: radical proposal: move IRC to Rocket.Chat
On Donnerstag, 10. August 2017 18:40:34 CEST Christian Loosli wrote: > Am Donnerstag, 10. August 2017, 17:25:14 CEST schrieb Jonathan Riddell: > > LibreOffice are having a similar discussion > > > > https://listarchives.libreoffice.org/global/projects/msg02257.html > > > > They want to continue using IRC though which means fragmentation would > > continue. > > Maybe someone should inform them that there are bridges available to avoid > that. > > But maybe they'd simply ignore that, multiple times, and go on, as some > people seem to do in this thread as well *shrug* Who ignored the possibility of bridges? Where does Martin Steigerwald's impression come from that people want to make this an "either/or decision"? The only person who seems to want to get rid of IRC is Jonathan, because he thinks bridges have a negative impact on the experience of both sides of them. I never said that. Martin Klapetek never said that. Yes, we both think that IRC is not suitable as the _only_ chat tool for a community in 2017. Why do people feel something is threatened without people threatening it? Puzzled, Thomas
Re: How about an inclusive "and" approach instead of fighting IRC versus something new? (was: Re: Collecting requirements for a KDE-wide instant messaging solution)
Martin Klapetek - 10.08.17, 12:34: > On Thu, Aug 10, 2017 at 3:24 AM, Martin Steigerwald > wrote: > > Martin Klapetek - 09.08.17, 16:12: > > > > But KDE is not a tech startup. As people correctly wrote, KDE has a > > > > very > > > > long > > > > history and contributors of all age. I'd rather be that than one of > > > > the > > > > many > > > > tech startups with a bunch of little to no experience but fancy new > > > > chat > > > > systems, to be honest. Do we really want and need to cater these > > > >mystical > > > > tweens so much? > > > > > > Yes. Old contributors will slowly fade away for various > > > reasons, be it life, be it lack of energy, be it other commitments. > > > Who's going to pick all those projects up after them? I'd like > > > to think that young enthusiasts with lots of energy and potential, > > > exactly what those heroes starting the original KDE were. > > > And I think we should strive to attract younger talent that can > > > be in it for the long run. > > > > Well, I wonder since reading several posts here about one thing: > > > > To from reading this post and other posts I got the impression that is > > absolutely needs to be black or white: > > > > *Either* IRC and nothing else *or* something new and nothing else. > > > > Seriously? > > > > I mean: Seriously? > > > > > > There has been almost completely unnoticed posts mentioning bridges. Is > > none > > of this bridges capable to work well enough for KDE community use cases? > > > > Why do you see the need to exclude either one of the groups? > > As you're quoting my email - where are you reading this? > That's not what I wrote at. all. I merely stated that we should > cater to younger engineers. Not once I suggested and will not > suggest to disregard the old timers. That was twisted in replies > following my email. Martin, I noted a general impression I got from the thread. You are right, you didnĀ“t write that. This either/or approach is what in my perception was in this thread since quite a whileā¦ probably not (always) explicitely written outā¦ but between the lines. It might have been wiser to choose a different post ā or even just donĀ“t quote any post at all ā to reply to with this. Sorry. Martin -- Martin
Re: radical proposal: move IRC to Rocket.Chat
Am Donnerstag, 10. August 2017, 17:25:14 CEST schrieb Jonathan Riddell: > LibreOffice are having a similar discussion > > https://listarchives.libreoffice.org/global/projects/msg02257.html > > They want to continue using IRC though which means fragmentation would > continue. Maybe someone should inform them that there are bridges available to avoid that. But maybe they'd simply ignore that, multiple times, and go on, as some people seem to do in this thread as well *shrug* Christian
Re: How about an inclusive "and" approach instead of fighting IRC versus something new? (was: Re: Collecting requirements for a KDE-wide instant messaging solution)
On Thu, Aug 10, 2017 at 3:24 AM, Martin Steigerwald wrote: > Martin Klapetek - 09.08.17, 16:12: > > > But KDE is not a tech startup. As people correctly wrote, KDE has a > very > > > long > > > history and contributors of all age. I'd rather be that than one of the > > > many > > > tech startups with a bunch of little to no experience but fancy new > chat > > > systems, to be honest. Do we really want and need to cater these > mystical > > > tweens so much? > > > > Yes. Old contributors will slowly fade away for various > > reasons, be it life, be it lack of energy, be it other commitments. > > Who's going to pick all those projects up after them? I'd like > > to think that young enthusiasts with lots of energy and potential, > > exactly what those heroes starting the original KDE were. > > And I think we should strive to attract younger talent that can > > be in it for the long run. > > Well, I wonder since reading several posts here about one thing: > > To from reading this post and other posts I got the impression that is > absolutely needs to be black or white: > > *Either* IRC and nothing else *or* something new and nothing else. > > Seriously? > > I mean: Seriously? > > > There has been almost completely unnoticed posts mentioning bridges. Is > none > of this bridges capable to work well enough for KDE community use cases? > > Why do you see the need to exclude either one of the groups? > As you're quoting my email - where are you reading this? That's not what I wrote at. all. I merely stated that we should cater to younger engineers. Not once I suggested and will not suggest to disregard the old timers. That was twisted in replies following my email. Cheers -- Martin Klapetek
Re: radical proposal: move IRC to Rocket.Chat
LibreOffice are having a similar discussion https://listarchives.libreoffice.org/global/projects/msg02257.html They want to continue using IRC though which means fragmentation would continue. They find rocket.chat to have some limitations including that the clients aren't as bug free as they ought to be. Jonathan On 8 August 2017 at 16:52, Jonathan Riddell wrote: > Like all sensible open source communities we use IRC lots for real > time communication essential to making low bandwidth decisions in a > reasonable timeframe as well as socialising. > > 20 years ago IRC was cool but these days real-time communication in > the non-geek world long since moved other places such as WhatsApp, > Facebook Messenger which are infinately more user friendly than IRC. > In the geek-world it has moved to Slack and Telegram. So KDE finds > itself spread between three real time communication methods with IRC > still the strongest but many new people reluctant to use it as scary > and unfamiliar while Slack and Telegram smell of being proprietary and > lacking some of the free-form nature of IRC. > > So my radical proposal for today is to consider moving all our > real-time communications wholesale to Rocket.Chat. Like Slack it takes > much of it's basic setup from IRC with #channels that anyone can set > up. Unlike Slack it's all free software and we can run our own > servers. Like Telegram it works on phones fine. Unlike IRC it > supports media files and friendly user names. > > It has a native desktop client and we have a KDE one in progress with Ruqola. > https://rocket.chat/ > > I setup up a temporary server, do come along and say hi to evaluate it. > http://ec2-34-203-38-236.compute-1.amazonaws.com:3000/ > > I'm aware this will probably end up as a case of XCKD standards > https://xkcd.com/927/ but I thought it worth a shot. We have > difficulty attracting new contributors and our community is > fragmenting because of the dominance of IRC so worth considering > alternatives. > > Jonathan
Re: radical proposal: move IRC to Rocket.Chat
> On 10 Aug 2017, at 15:27, Marco Martin wrote: > > On Wed, Aug 9, 2017 at 7:57 PM, Albert Astals Cid wrote: >> You can't expect me to read a 200 messages backlog in 20 channels just in >> case >> something important was said while i was away. >> >> Also one of the reasons of why i hate to use Telegram for anything that >> "actually matters" is this "always on" feature. > > that's sooo true for me as well :) > and i guess it's the exact opposite of why so many people prefer > telegram over irc, but on my end, i *love* that when i'm offline, i'm > really offline > I get that point. The thing is that people who have grown up with modern IM systems have a different mindset. They are used to not missing anything while away, they just expect things to be that way. You always have the option to temporarily mute your IM appās notifications, though, but you canāt set āoffice hoursā and people donāt get a notification when they try to ping you while you have it muted. We could add āProvide easy way to set availability times and communicate non-availability to othersā to the requirements list, though. Slack has that, and itās really useful especially when you use it for work.
Re: radical proposal: move IRC to Rocket.Chat
On Wed, Aug 9, 2017 at 7:57 PM, Albert Astals Cid wrote: > You can't expect me to read a 200 messages backlog in 20 channels just in case > something important was said while i was away. > > Also one of the reasons of why i hate to use Telegram for anything that > "actually matters" is this "always on" feature. that's sooo true for me as well :) and i guess it's the exact opposite of why so many people prefer telegram over irc, but on my end, i *love* that when i'm offline, i'm really offline -- Marco Martin
Re: github, phabricator: a new threadZ
On Thu, Aug 10, 2017 at 11:06 AM, Adriaan de Groot wrote: > Perhaps we should ask sitter what kinds of scratch repo's those were, and > whether he would have created them on KDE infra, if there was a similarly > simple one-click way to create scratch repo's. - experimental snap build tooling for neon's jenkins - experimental os-autoinst (openqa) tooling - experimental jenkins plugins (later migrated to git.kde for rollout) - experimental api.projects.kde.org (later migrated to git.kde for rollout) - experimental appstream health to junit converter - experimental filelight-ming32 build using only cmake - experimental plasmoid to track packagekit activity (later migtated to git.kde) - experimental dbus traffic recording and playback system for mocking services on a dbus level - various rbot plugins (later migrated to git.kde) - assistive service for logind session cleanup for racnoss (later migrated to git.kde) - sftp-to-http bridging service for neon's jenkins to get access to pre-release tarballs - experimental snap bundle running an entire plasma desktop - experimental apache config example for transparent fallback from drupal to a static set of pages on 404 - migration script for kanboard to phabricator (which was used to migrate KDE todos) - some other experimental helpers mostly to assist with one of the aforementioned things Everything denoted experimental was created not knowing if this is production viable or even worth seeing through to production quality. Barring a minor problem with git.kde not being able to support https clones with `go get` I'd probably have created them all as "throw-away" repos on KDE infrastructure since there is no immediate benefit to these things being on github. For good measure in the same time period I've forked or worked on forks of the following on github: - aptly (repo server used by neon) - appstream & appstream-generator - various jenkins plugins - the bot service which closes PRs against KDE's github mirror repos - repology (distro-package-version-tracking website) - various ruby gems - snapd & snapcraft - packagekit On that note: anecdotal evidence suggests that a lot of jenkins plugins suffer from the "dead repo" problem often mentioned. 3/3 plugins I submitted PRs against have not gotten a review or only after months sitting there. They are all under the shared community jenkinsci organization though. And on a further note since I write a lot of ruby: I'd have to think twice or trice about putting "vast/complex/more than a bunch of lines" ruby software on KDE infrastructure, even if the software was very related to a KDE project. I'd miss out on easy access to the vast ruby ecosystem centered around github. That's not necessarily an infrastructure fault on our side, but I thought I'd mention it. Food for thought: maybe KDE infra should feel similarly like a want-have when writing qt software. HS
Re: github, phabricator: a new threadZ
Op donderdag 10 augustus 2017 11:06:21 CEST schreef Adriaan de Groot: > On Thursday 10 August 2017 10:45:14 Harald Sitter wrote: > > Seems to me y'all aren't appreciating that I am telling you my point > > of view. I have created some 20 repos on github last year and 0 > > scratch repos on our infrastructure. I thought you might want to know > > why. Feel free to find my reasons silly, that doesn't change them > > though. > > - KDE scratch repo's are not widely known within the KDE community. > - KDE scratch repo's take more effort to create, and for scratchj / > throwaway repo's, every bit of extra effort is one. Scratch repos can be made without a browser. git init git remote add origin kde:scratch/vandenoever/itchfix git push --all origin https://community.kde.org/Sysadmin/ GitKdeOrgManual#Personal_scratch_repositories Cheers, Jos signature.asc Description: This is a digitally signed message part.
Re: Collecting requirements for a KDE-wide instant messaging solution
On Wed, Aug 09, 2017 at 08:51:53PM +0200, Christian Loosli wrote: > Then, on the subject of emojis, stickers or even the protocol used being so > important: > > Let's see what others do. My proposal is to lead rather than follow others. We can learn from their experience but leading would be better. > But even if it would: to be honest, if someone decides what project they want > to contribute due based on what chat protocol they use internally, I'm > personally not sure if that is a well suited candidate due to rather odd > priorities. It's not a concious decision, it's a preference which would lead to being being more or less involved. Jonathan
Re: How about an inclusive "and" approach instead of fighting IRC versus something new? (was: Re: Collecting requirements for a KDE-wide instant messaging solution)
> What Iāve argued strongly against is the standpoint that we should stick > with the status quo. The status quo _is_ things with the advantages of Telegram or Matrix available, since these two are already bridged. Hence my earlier > Last but not least: if IRC really is so much of an issue, which I doubt: there are solutions readily available (Tg and Matrix bridge) or available in the future (Rocket bridge) which do resolve the problem whilst still maintaining compatibility for people who prefer what worked for 20 years and still works. So the reasons to continue with a replacement I can see are either "We want to get rid of the other one completely and enforce this one" or "we want it NOW", both of which I heavily have to disagree with [...] If you want Rocket, for whatever reason, see my other post which was so far mostly ignored.
Re: How about an inclusive "and" approach instead of fighting IRC versus
On Thu, Aug 10, 2017 at 09:24:08AM +0200, Martin Steigerwald wrote: > *Either* IRC and nothing else *or* something new and nothing else. > > Seriously? > > I mean: Seriously? I'm always serious :) But sure it's a long shot and I never expected it to happen, but I thought I'd try. Moving wholesale to something which has the advantages of IRC and the advantages of Telegram would avoid fragmentation that I see and it would avoid the faff of bridges which makes it even harder to follow who is who on each place. Jonathan
Re: Please participate in the requirements Etherpad (Was: Re: radical proposal: move IRC to Rocket.Chat)
On Thursday 10 August 2017 10:57:29 Adriaan de Groot wrote: > This is a microcosm, a textbook example, a beautiful illustration of > exactly what the culture-worries in the IM thread are about Perhaps to clarify: the above is a philosophical point (see what happens when you start messing around with communications channels), not related to the actual list being created. The list being created so far is (as Thomas mentioned) at https://notes.kde.org/p/KDE_IM_requirements You will need a KDE identity account to access it. If I glance at the colors in that notepad (even though few have attached their name to a color), it looks like all the vocal people in this thread are also represented on the notepad. There are interesting philosophical discussions to be had about the content of the list -- but not just yet, I don't think. [ade]
Re: How about an inclusive "and" approach instead of fighting IRC versus something new? (was: Re: Collecting requirements for a KDE-wide instant messaging solution)
> On 10 Aug 2017, at 10:22, Luigi Toscano wrote: > > Il 10 agosto 2017 10:24:08 EEST, Martin Steigerwald ha > scritto: >> Martin Klapetek - 09.08.17, 16:12: But KDE is not a tech startup. As people correctly wrote, KDE has a >> very long history and contributors of all age. I'd rather be that than one of >> the many tech startups with a bunch of little to no experience but fancy new >> chat systems, to be honest. Do we really want and need to cater these >> mystical tweens so much? >>> >>> Yes. Old contributors will slowly fade away for various >>> reasons, be it life, be it lack of energy, be it other commitments. >>> Who's going to pick all those projects up after them? I'd like >>> to think that young enthusiasts with lots of energy and potential, >>> exactly what those heroes starting the original KDE were. >>> And I think we should strive to attract younger talent that can >>> be in it for the long run. >> >> Well, I wonder since reading several posts here about one thing: >> >> To from reading this post and other posts I got the impression that is >> absolutely needs to be black or white: >> >> *Either* IRC and nothing else *or* something new and nothing else. >> >> Seriously? >> >> I mean: Seriously? >> >> >> There has been almost completely unnoticed posts mentioning bridges. Is >> none >> of this bridges capable to work well enough for KDE community use >> cases? > > I see it differently; I see people wanting something that also works with IRC > (so bridges, starting with the ones that already works) and people that don't > want IRC even if it's working in the background without then having to care > about it. Who did ever say that? I certainly didnāt. Throughout the entire discussion, I have always been 99.99% certain that we will end up with something thatās bridged to IRC. Why would we not? There is not really a downside to it as long as the bridge works well, is there? What Iāve argued strongly against is the standpoint that we should stick with the status quo.
Re: github, phabricator: a new threadZ
On Thursday 10 August 2017 10:45:14 Harald Sitter wrote: > Seems to me y'all aren't appreciating that I am telling you my point > of view. I have created some 20 repos on github last year and 0 > scratch repos on our infrastructure. I thought you might want to know > why. Feel free to find my reasons silly, that doesn't change them > though. So, since this is the thread for requirements-collecting on github, phabricator, KDE git infrastructure, we have some data points: - KDE scratch repo's are not widely known within the KDE community. - KDE scratch repo's take more effort to create, and for scratchj / throwaway repo's, every bit of extra effort is one. I suppose if I had a browser window open, and logged in to KDE phab and github at the same time, and the one tab gives me instant gratification (and a scratch repo) while the other gives me gratification four clicks and a few minutes away, then the one it is. Buut .. that presupposes that people create scratch repo's wherever is convenient, not wherever they make sense. So the initial question that kicked off this thread, (I can't spot who asked it though) >>> >> should also think about. Why many KDE developers choose github instead >>> >> of scratch KDE repositories to start new software, where it could >>> >> happily be hosted within KDE infrastructure? presupposes that those scratch repo's could be created and hosted within KDE infrastructure (I personally would only create scratch repo's on KDE infrastructure for things that have something to do with KDE and can fall within the KDE manifesto). Perhaps we should ask sitter what kinds of scratch repo's those were, and whether he would have created them on KDE infra, if there was a similarly simple one-click way to create scratch repo's. [ade]
Re: Please participate in the requirements Etherpad (Was: Re: radical proposal: move IRC to Rocket.Chat)
On Thursday 10 August 2017 00:15:21 Thomas Pfeiffer wrote: > Just in case my other email linking to the Etherpad was overlooked by some > of you because it was buried too deep in the thread: > > Let's make this discussion productive by collecting the requirements KDE has > for a chat / IM system to become our standard in this document: > > https://notes.kde.org/p/KDE_IM_requirements > > This is supposed to be the basis for our evaluation and ultimately decision, > so if you don't contribute, you don't get to complain later ;) The thing is, you suddenly changed communications mechanisms, added an authentication step, and changed the format for listing the requirements. That fragments the discussion between the original group participating, and the group that moves to the new(er) communications protocol. And now you're saying that those that do not move to the new protocol, don't deserve to have (had) a voice? This is a microcosm, a textbook example, a beautiful illustration of exactly what the culture-worries in the IM thread are about: you're going to lose people (for sure) and you're going to attract people (possibly), but the most effective thing to do in communication is to keep everyone in the loop. (That said, I applaud the attempt to work together towards the creation of a list in a medium that is more conducive to reaching a "this is the document" than an email thread.) [ade]
Re: github, phabricator: a new threadZ
Il 10 agosto 2017 11:45:14 EEST, Harald Sitter ha scritto: >Seems to me y'all aren't appreciating that I am telling you my point >of view. One thing is say "adding an easier workflow for scratch repo to our infra is much required for this and that", which I can agree too; another is going straight to something that seems more like to "ready to kill our infra anytime". > I have created some 20 repos on github last year and 0 >scratch repos on our infrastructure. I thought you might want to know >why. Feel free to find my reasons silly, that doesn't change them >though. I don't find your reasoning silly, as I wrote above. Hyperbole(s?) are fine but maybe distracting in an already complicated discussion. -- Luigi
Re: github, phabricator: a new threadZ
Seems to me y'all aren't appreciating that I am telling you my point of view. I have created some 20 repos on github last year and 0 scratch repos on our infrastructure. I thought you might want to know why. Feel free to find my reasons silly, that doesn't change them though. I am did not mean to argue any side. On Thu, Aug 10, 2017 at 9:02 AM, Harald Sitter wrote: > I for one would pick the alternative which is not using our > infrastructure and instead click two buttons so I don't have to file > paperwork manually nor have to wait for said paperwork to get faxed to > HQ for approval. i.e. not waiting trumps waiting in my world. > > On Wed, Aug 9, 2017 at 8:05 PM, Albert Astals Cid wrote: >> El dimecres, 9 dāagost de 2017, a les 13:50:46 CEST, Harald Sitter va >> escriure: >>> On Wed, Aug 9, 2017 at 1:39 PM, Boudewijn Rempt wrote: >>> > On Wed, 9 Aug 2017, Riccardo Iaconelli wrote: >>> >> This is a new thread entirely, but incidentally also something we >>> >> should also think about. Why many KDE developers choose github instead >>> >> of scratch KDE repositories to start new software, where it could >>> >> happily be hosted within KDE infrastructure? >>> > >>> > Our infra doesn't offer scratch repos anymore, does it? >>> >>> It does, they were slated for removal with the transition to phab, >>> since that hasn't happend yet though I assume scratch repos are still >>> a thing. Albeit, a thing that is meant to be removed with (currently) >>> no replacement planned >> >> That was not the plan, the plan (unless it has changed since last time i >> asked) is to have a team of "trusted people" that can create repos on >> phabricator, so basically you'd open a ticket and you'd get a repo created in >> a matter of minutes, not automagic, but surely you can continue coding for 15 >> minutes while you wait for your repository to be created. >> >> Cheers, >> Albert >> >>> which is why for example I do not create any >>> new ones and instead use github. Although TBH the UX of creating a >>> scratch has also left me wanting as it entails me googling how to >>> setup a scratch every single time. >>> >>> HS >> >>
Re: How about an inclusive "and" approach instead of fighting IRC versus something new? (was: Re: Collecting requirements for a KDE-wide instant messaging solution)
Il 10 agosto 2017 10:24:08 EEST, Martin Steigerwald ha scritto: >Martin Klapetek - 09.08.17, 16:12: >> > But KDE is not a tech startup. As people correctly wrote, KDE has a >very >> > long >> > history and contributors of all age. I'd rather be that than one of >the >> > many >> > tech startups with a bunch of little to no experience but fancy new >chat >> > systems, to be honest. Do we really want and need to cater these >mystical >> > tweens so much? >> >> Yes. Old contributors will slowly fade away for various >> reasons, be it life, be it lack of energy, be it other commitments. >> Who's going to pick all those projects up after them? I'd like >> to think that young enthusiasts with lots of energy and potential, >> exactly what those heroes starting the original KDE were. >> And I think we should strive to attract younger talent that can >> be in it for the long run. > >Well, I wonder since reading several posts here about one thing: > >To from reading this post and other posts I got the impression that is >absolutely needs to be black or white: > >*Either* IRC and nothing else *or* something new and nothing else. > >Seriously? > >I mean: Seriously? > > >There has been almost completely unnoticed posts mentioning bridges. Is >none >of this bridges capable to work well enough for KDE community use >cases? I see it differently; I see people wanting something that also works with IRC (so bridges, starting with the ones that already works) and people that don't want IRC even if it's working in the background without then having to care about it. > >Why do you see the need to exclude either one of the groups? Exactly my point. -- Luigi
Re: github, phabricator: a new threadZ
Il 10 agosto 2017 10:02:43 EEST, Harald Sitter ha scritto: >I for one would pick the alternative which is not using our >infrastructure and instead click two buttons so I don't have to file >paperwork manually nor have to wait for said paperwork to get faxed to >HQ for approval. i.e. not waiting trumps waiting in my world. > Nothing technically prevents this from implementing this in oir infrastructure, nor what Albert wrote hints at this: he just reported the current plan. Plan can be changed. I don't understand the need of "let's trow everything out of.the window" instead of "let's extend what we have" (same goes for the proper IM discussion) Let me requote: >On Wed, Aug 9, 2017 at 8:05 PM, Albert Astals Cid >wrote: >> That was not the plan, the plan (unless it has changed since last >time i >> asked) is to have a team of "trusted people" that can create repos on >> phabricator, so basically you'd open a ticket and you'd get a repo >created in >> a matter of minutes, not automagic, but surely you can continue >coding for 15 >> minutes while you wait for your repository to be created. >> >> Cheers, >> Albert -- Luigi
Re: Collecting requirements for a KDE-wide instant messaging solution
On 08/09/2017 07:19 AM, Thomas Pfeiffer wrote: > Must-have: - dfaure is there so I can ask KIO questions (IRC fails that currently.) Cheers, Eike
Re: Please participate in the requirements Etherpad
Thomas Pfeiffer - 10.08.17, 00:15: > Just in case my other email linking to the Etherpad was overlooked by some > of you because it was buried too deep in the thread: > > Let's make this discussion productive by collecting the requirements KDE has > for a chat / IM system to become our standard in this document: > > https://notes.kde.org/p/KDE_IM_requirements > > This is supposed to be the basis for our evaluation and ultimately decision, > so if you don't contribute, you don't get to complain later ;) I added aspects of inclusion to that (make both IRC and new chat system users happy instead of triggering energy wasting fights between those two groups, have a GUI for people with disabilities). Thanks, -- Martin
Re: github, phabricator: a new threadZ
On Thu, Aug 10, 2017 at 7:02 PM, Harald Sitter wrote: > I for one would pick the alternative which is not using our > infrastructure and instead click two buttons so I don't have to file > paperwork manually nor have to wait for said paperwork to get faxed to > HQ for approval. i.e. not waiting trumps waiting in my world. The reason why it's restricted right now is because creating a repository with Gitolite requires the ability to push to gitolite-admin, which also means you can change SSH Keys and thus become them as far as the system is concerned. I dislike your use of terminology there regarding paperwork being faxed to HQ - Sysadmin hasn't ever declined a developers request for a repository. We have on occasion suggested different names, to keep to conventions (for Plasmoids and packaging repositories for instance) or where a developer has chosen a heavily generic and non-descriptive names. Repository names that don't follow conventions or which are non-descriptive are harmful as they interfere with the discoverability of code. Oh, and you're neglecting to mention that scratch repositories very much still exist, and require basically no effort to use. Not even a Sysadmin ticket. > > On Wed, Aug 9, 2017 at 8:05 PM, Albert Astals Cid wrote: >> El dimecres, 9 dāagost de 2017, a les 13:50:46 CEST, Harald Sitter va >> escriure: >>> On Wed, Aug 9, 2017 at 1:39 PM, Boudewijn Rempt wrote: >>> > On Wed, 9 Aug 2017, Riccardo Iaconelli wrote: >>> >> This is a new thread entirely, but incidentally also something we >>> >> should also think about. Why many KDE developers choose github instead >>> >> of scratch KDE repositories to start new software, where it could >>> >> happily be hosted within KDE infrastructure? >>> > >>> > Our infra doesn't offer scratch repos anymore, does it? >>> >>> It does, they were slated for removal with the transition to phab, >>> since that hasn't happend yet though I assume scratch repos are still >>> a thing. Albeit, a thing that is meant to be removed with (currently) >>> no replacement planned >> >> That was not the plan, the plan (unless it has changed since last time i >> asked) is to have a team of "trusted people" that can create repos on That group has for the most part been established already, and is known as #Community_Admins. It's full membership can be seen at https://phabricator.kde.org/project/members/27/ Once we move to using Phabricator for hosting repositories they'll have the power to create a repository in about 4 clicks. They currently have the power to fully edit tasks (including visibility and edit rights), create and edit all projects, setup short urls (go.kde.org), manage global Herald rules and setup top level Wiki namespaces on Phabricator among other things. >> phabricator, so basically you'd open a ticket and you'd get a repo created in >> a matter of minutes, not automagic, but surely you can continue coding for 15 >> minutes while you wait for your repository to be created. In terms of a scratch repositories, we just haven't figured out how those should be handled in Phabricator yet. Given the fact people have issue with how they work now, one of the possible solutions floated at the time was that we would retire them. It is possible a more limited version of the create repository flow will be offered to developers who aren't community admins which will set repositories up (but not allow editing them), but this would require custom code (likely as a Phabricator extension). >> >> Cheers, >> Albert >> >>> which is why for example I do not create any >>> new ones and instead use github. Although TBH the UX of creating a >>> scratch has also left me wanting as it entails me googling how to >>> setup a scratch every single time. >>> >>> HS >> >> Regards, Ben
Re: Collecting requirements for a KDE-wide instant messaging solution (was: Re: radical proposal: move IRC to Rocket.Chat)
Christian Loosli - 09.08.17, 22:26: > > Who's going to pick all those projects up after them? I'd like > > to think that young enthusiasts with lots of energy and potential, > > exactly what those heroes starting the original KDE were. > > Who is going to be there for these new talents that lack experience? > > You need both, thus catering for one group specifically is, in my opinion, > stupid. *thank you* I just wrote a post about making this very clear. Please stop fighting "either / or". It wonĀ“t work. It easily visible from the structure of this thread already. How can some new chat system lovers and IRC users be happy? Thanks, -- Martin
How about an inclusive "and" approach instead of fighting IRC versus something new? (was: Re: Collecting requirements for a KDE-wide instant messaging solution)
Martin Klapetek - 09.08.17, 16:12: > > But KDE is not a tech startup. As people correctly wrote, KDE has a very > > long > > history and contributors of all age. I'd rather be that than one of the > > many > > tech startups with a bunch of little to no experience but fancy new chat > > systems, to be honest. Do we really want and need to cater these mystical > > tweens so much? > > Yes. Old contributors will slowly fade away for various > reasons, be it life, be it lack of energy, be it other commitments. > Who's going to pick all those projects up after them? I'd like > to think that young enthusiasts with lots of energy and potential, > exactly what those heroes starting the original KDE were. > And I think we should strive to attract younger talent that can > be in it for the long run. Well, I wonder since reading several posts here about one thing: To from reading this post and other posts I got the impression that is absolutely needs to be black or white: *Either* IRC and nothing else *or* something new and nothing else. Seriously? I mean: Seriously? There has been almost completely unnoticed posts mentioning bridges. Is none of this bridges capable to work well enough for KDE community use cases? Why do you see the need to exclude either one of the groups? I know for me personally: Its either IRC or something that feels like it, is as lightwight as it, as standardized as it and as free software as it (i.e. offers free software server and client). I use Quassel IRC and I am perfectly fine with following IRC channels using it. Heck even most other communities I communicate with like for games are on IRC. Basically it is all there. Butā¦ I wouldnĀ“t like to exclude anyone who does not want to use IRC eitherā¦ so canĀ“t there be one chat system with IRC + something new? Also I think for a community like KDE there needs to be balance between: - How much does KDE community adapts to its potential new members. - How much potential new members adapt to the KDE community. There needs to be a balance between what works already ā and I get the impression that both mailing lists and IRC do work for KDE community, just look at the accomplishments, just look at the achievements and you can know that beyond any trace of doubt ā and something new that could work for new people. Also do we really know who these potential new people are and what their preferences would be without a survey? I have been in Spain lately, and I learnt a little bit of the language. Seriously I wouldnĀ“t expect anyone to speak german just cause I happen to have my holidays there. However if someone there can speak some english or even a few words of german whenever I got stuck I appreciated it as well. I follow developements regarding new chat systems myself, I see that IRC is datedā¦ yet I also see that it works. For me it is no "either / or"ā¦ and I kindly ask you to consider that there can be an "and" that is more inclusive than any of the "either / or" options. Requirement for this "and" would be bridging, i.e. no matter which chat system out of the supported ones one usesā¦ she will always see all the messages from people who use other supported chat systems. From previously just reading this thread I am almost completely certain that there wonĀ“t be an agreement on one of the "either / or" options. Without recycling this further it can be pretty much clear that here are people who favor IRC and people who favor something new. So rather than wasting any more energy fighting against one another over which option will winā¦ I think the way forward would be to find a way to make both groups happy. Thank you for considering my plea to bring some sanity to this discussion again. Thanks, -- Martin
Re: github, phabricator: a new threadZ
I for one would pick the alternative which is not using our infrastructure and instead click two buttons so I don't have to file paperwork manually nor have to wait for said paperwork to get faxed to HQ for approval. i.e. not waiting trumps waiting in my world. On Wed, Aug 9, 2017 at 8:05 PM, Albert Astals Cid wrote: > El dimecres, 9 dāagost de 2017, a les 13:50:46 CEST, Harald Sitter va > escriure: >> On Wed, Aug 9, 2017 at 1:39 PM, Boudewijn Rempt wrote: >> > On Wed, 9 Aug 2017, Riccardo Iaconelli wrote: >> >> This is a new thread entirely, but incidentally also something we >> >> should also think about. Why many KDE developers choose github instead >> >> of scratch KDE repositories to start new software, where it could >> >> happily be hosted within KDE infrastructure? >> > >> > Our infra doesn't offer scratch repos anymore, does it? >> >> It does, they were slated for removal with the transition to phab, >> since that hasn't happend yet though I assume scratch repos are still >> a thing. Albeit, a thing that is meant to be removed with (currently) >> no replacement planned > > That was not the plan, the plan (unless it has changed since last time i > asked) is to have a team of "trusted people" that can create repos on > phabricator, so basically you'd open a ticket and you'd get a repo created in > a matter of minutes, not automagic, but surely you can continue coding for 15 > minutes while you wait for your repository to be created. > > Cheers, > Albert > >> which is why for example I do not create any >> new ones and instead use github. Although TBH the UX of creating a >> scratch has also left me wanting as it entails me googling how to >> setup a scratch every single time. >> >> HS > >
