Re: [kde-community] Your mission, should you choose to accept it, is.....
On Thursday, September 11, 2014 03:56:01 PM Arjun Ak wrote: How about having something similar to the eudyptula challenge (http://eudyptula-challenge.org/) ? This is orthogonal to this idea. The Eudyptula challenge is about educating people whereas our proposal is about adjusting our workflow so as to make it easier to include and attract new people. Having said that, I think that the idea of having an automized online workshop for KDE development similar to the Eudyptula challenge would be very helpful. Please open another thread if you want to talk more about this possibility. Best regards, Peter ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Your mission, should you choose to accept it, is.....
On Saturday, September 13, 2014 01:03:12 PM Claus Christensen wrote: This is a great idea. I wouldn't mind putting in some work to make something like this get off the ground. Awesome, a volunteer! You wouldn't happen to have any experience in web development or desire to learn about it, would you? :) Best regards, Peter ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Your mission, should you choose to accept it, is.....
Hello everyone, some of us who missed the day trip today in Brno were discussing ways to get new or less proactive people involved with KDE. Right now, we are a community of very proactive, inner-directed people. We find something to do, or make up something to do that makes us happy. It would be great to have people who are not of this personality or those who have no idea where to start, to get a nice choice of what we know we need. The vague idea is to offer people descriptions of missions that they can take up, to lower the barrier of entry. What we have come up with is a proposal to reuse part of Brainstorm, and extend that in a new direction. We envision a unified place where developers aggregate missions of different size and scope. This place is meant to be the go-to place for people who want to get involved with KDE, accessible through a prominent get involved link on kde.org. The kind of missions we envision are: * Junior Jobs * GSoC, SoK, GCi * new team members wanted * specific areas needing attention * applications and libraries needing maintainers Brainstorm is a place for users to dream about cool stuff, and even vote up the ideas. What has been missing is developer buy-in, as we understand it. Right now there is a section in Brainstorm called In Development. What we are proposing is to launch Mission on the Forum as well. Project managers could close threads and link to the new Mission. This could also be a place to integrate idea generation for GSoC projects, Summer of KDE , even GCi tasks, possibly allowing users to rate them in importance. If we can get in the habit of doing this all year round, getting ready for GSoC, SoK, and GCi will be easier. We have our first mission, once this is created on the Forum: https://blogs.kde.org/2014/08/16/konqueror-looking-maintainer Valorie Zimmerman Michael Bohlender Heinz Wiesinger David Faure Peter Grasch ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] help inform about Akademy
On Monday, August 04, 2014 10:51:46 PM Franklin Weng wrote: Oh, okay, I didn't noticed that. Thanks for informing. No worries :) Best regards, Peter ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] Squish UI Testing
Hi, I remember hearing that froglogic sponsored a license for their Squish GUI testing framework for KDE developers a (long) while ago. Is this offer still valid? Thanks. Best regards, Peter ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] SCRUM in KDE
Hey, On 03/03/2014 06:56 PM, Ivan Čukić wrote: Not sure whether this is the topic for kde-community, but here it goes... :) Hm... sue me :) for this years Open Academy project, we have decided to use SCRUM. I have looked at tools that could help us implement the various practices and found Icescrum (http://www.icescrum.org/). I installed it on my own infrastructure and so far I'm very happy with it. We have had a chance to play around with IceScrum during the Plasma Active development. People weren't really satisfied with it. It was fun to drag the stickers around, but it was problematic from time to time. (I'm hoping somebody will remember the actual issues we have had, since I don't :) ) Yeah, I heard about that from Aaron as well. So far, I'm still in the stage were moving stickers around is entirely enough to keep me entertained, so I'll have to wait and see. The online reviews are quite positive, fwiw. Is there interest from the membership? Should we maybe look into having a central instance of Icescrum (or an equivalent) on the KDE infrastructure? IIRC, there is (was?) something in the works regarding this. I remember that a few systems were being tested half a year ago, with the intention to choose one for Plasma (as the guinea pig, and later other projects), but I haven't heard anything regarding that since. Would be very interested about this. Best regards, Peter ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Discussion: KDE Manifesto, established practices
Hey guys, sorry for not replying sooner, I just got back from some travel. I completely agree that the old language was essentially meaningless when it comes to enforcement but I thought that this was more or less on purpose: Lax language allows us to convey the idea (do, how we do) without needing to specify the details and - again - gives us much more freedom to act. But apparently we want to make this clause carry actual weight. That's alright but then the updated language is imho also far from ideal: All three of your use cases fail completely without a clear definition of what constitutes an established practice. I know we want to keep the manifesto short and to the point but if we want the language to be precise enough to invoke in case of dispute, it needs to actually be *precise*. So, to sum up, my position is to either a.) keep the language as is: Legally meaningless, just to convey intention b.) make it precise enough to clear up any confusion. only then it becomes actually enforceable. This would imho include a list of the established practices we're referring to - with links to their full policies. Best regards, Peter ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Discussion: KDE Manifesto, established practices
On 11/12/2013 06:35 PM, Aaron J. Seigo wrote: 1) where exceptions are appropriate, they are encoded into the individual descriptions of “established practices”. we have a commit policy, for instance; it probably has exceptions to its guidelines. those exceptions belong in the commit policy, not the Manifesto. since those exceptions are in the commit policy, they are part of the established practice of the commit policy, and therefore the Manifesto does not need to add yet another “escape clause” on top of that. Agreed. 2) the point of enumerating the attributes of a “KDE Project” is to ensure a certain continuity amongst those projects. if we want to be permissive and let anything go, we don’t need a Manifesto, a Code of Conduct or even a commit policy. as we agree those things have utility, we need to be willing to accept that there may be projects that will not demonstrate the necessary attributes. Agreed. 3) if there are undefined escape clauses in the “what it means to be a KDE Project”, even if we don’t intend them to be used in that manner, people will use them to justify behavior that we explicitly do not want. they will point to the Manifesto and say “well, you guys said that if there are special considerations .. and we have them”. the “special considerations” clause is a trap dug for ourselves that will be used by the very sorts of projects the Manifesto ought to help us identify as “not belonging to KDE Disagreed. Actually, any person that takes whatever we may write so literally as you are portraying in your email will always get it wrong. Something as faceted as a full software development cycle just can't be adressed in detail in half a sentence. I could just as easily argue that the new language would have caused e.g., the Necessitas people to go ah, we can't conform to the established practices so we obviously can't be a KDE project. This, actually, nicely brings me to my point: Because the meaning behind that point is complex, we should err on the side of caution on making it too restrictive. The ambiguity in the original language is imho an *advantage* because it is indicative of the actual practice: special considerations may arise that are to be treated on a case-by-case basis. No, we can't give a list of valid considerations but that doesn't mean there won't be any that warrant exceptions. We've done it in the past and will do it again. What is important is that there is *communication* - something that a strict wording imho hinders. It was my understanding that attracting such diverse project to the KDE umbrella was recognized as being in our best interest and something we want to encourage. we want to attract a diversity of projects, but within principles that have gained consensus over the years and become part of KDE’s culture. we do exclude projects even now: we could attract more projects by dropping the Free software requirement. You misunderstood me here. I'm not saying we change our policies and become more open toward potential special considerations in the future. I'm saying that keeping the clause as we have it now better indicates our actual practice. Saying that there can be special considerations doesn't lock us into granting exceptions all the time. This would be akin to saying killing people is legal because it is in certain specific circumstances (self-defence, for example). being overly permissive leads to there being no identification of “KDE” and it is exactly that community and culture that leads to a group of diverse projects being able to work together. Agreed. I don't think that the clause as it stands today can really be seen as a wildcard for projects to do what they want. (And, afaik, this also then what are the boundaries of “special conditions? If we could anticipate them, they wouldn't be all that special. So, to answer your question: to be determined on a case by case basis. hasn't been a problem as of yet but please correct me if I'm wrong here.) you don’t buy insurance after your house burns down. the Manifesto has not been around long enough for it to become an issue, but it is plain to see how it can and will be. Obviously we should be proactive but I want to point out that the fear of people exploiting the Manifesto is not just unfounded in theory (as it's not a binding document) but - so far - also in practice. What these few simple words do signal, however, is that while we do have rules, KDE is a community of human beings that can be talked to instead of a faceless set of laws. The project stays true to established practices common to similar KDE projects” how can you claim that that is a faceless set of laws? it doesn’t even use the word “policy” but rather practice. Okay, this may have been harsh language on my side. This is not what I meant. I apologize. Let me try to explain what I mean: Suppose there is a project team that considers moving to
Re: [kde-community] Discussion: KDE Manifesto, established practices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/11/2013 06:35 PM, Aaron J. Seigo wrote: On Monday, November 11, 2013 12:16:38 Peter Grasch wrote: These people can not expected to know that deviating in case of special considerations is standard practice within the KDE community. not at all. the key phrase is established practices”. so, the established practice of, say, respecting string freezes. yes, there are exceptions to that rule, but those exceptions are codified *in the establishment of the practice of release engineering*. if a given practice establishes *for itself* exceptions, then those exceptions are part of the “established practices”. IIRC, this clause was put there - among other reasons, some of which you address - to justify e.g. Necessitas and even Owncloud not following a whole range of our established practices. It was my understanding that attracting such diverse project to the KDE umbrella was recognized as being in our best interest and something we want to encourage. I don't think that the clause as it stands today can really be seen as a wildcard for projects to do what they want. (And, afaik, this also hasn't been a problem as of yet but please correct me if I'm wrong here.) What these few simple words do signal, however, is that while we do have rules, KDE is a community of human beings that can be talked to instead of a faceless set of laws. To me, this is a really important point and also something that is often surprising to people who haven't interacted with FOSS communities before. But maybe this is just me misinterpreting it, so let's stay with a practical example: How would Necessitas be justified under the KDE umbrella given the updated language? Best regards, Peter -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSgYntAAoJEFCPmK2EvjqqfrkQALuNK60HiweaM+jLux5CrdGg mKiY4A00dtyimatW31vn99QEtEdecXh8yFg6zrvRxgOu86XU2Zb9FmPFWGzHBCRG GaTs0OYeDRX9//6H6y3/D5cJryMRGyHgwer8FVKLHJPYtxEmVS8osc2t8kuNnUil cilpmqiCC6uDHHUoMldP86UY6MEer0uzc/k+vsRFf0cnzsgBw9ogj6V/rYdfuLfE emp9nqCxxu4DNNq9TfCJS0BaxHiafu3RblFCSDfFyLGk4bA3xXlaAJ9K7opJnMXl 7Cu6WBo29xCxV1yLb7MLxl/ID+FRe8tqgzyJXnnqAZ6ayfMmxbVlKSltMG42rrrG KujSxBSjajsiVnEd14U/Rpt9yqvhe4vbAy1D7xecUQ6owjw3Hxj6UEMBt5/eA6HW 2yXkgkSD0ahuGD9OWMR2C0B/T0ST+a+fQAnN0f7fYSrfFm+BOR+4eT4b+boanmmC 9qxO3rzgxQC9VVgKK/yWRFhUGXnnroa077iYsND5qCLPVg4SwMAcOJqQJBH4pYzE IgjBR7BY4U+gPbL6MLQQLj0wBlKwdkNK6Z19wzTKLjKGBZA47fVWf1E2+df7N2rt q7Umgd4f5ZC0+KoCypN4CYZErl7dLxKp1o8w8cNXb8PiLzQMWAMPin0orejPx8IW C4NEwZEp8Fq83pZF0GKG =XPZh -END PGP SIGNATURE- ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] The Future of Speech Recognition in KDE: Proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/04/2013 08:35 PM, Lydia Pintscher wrote: On Sat, Aug 31, 2013 at 11:59 AM, Peter Grasch pe...@grasch.net wrote: I'm posting this here on the community list because I want to hear your thoughts on the proposal. Do you think that the 'open speech group' would fit within KDE? The work you've done so far is outstanding and I'm always delighted to see KDE provide accessibility features thanks to your work. So a big +1 from me to expand this and move it further. Thank you. I feel like there have been a lot of positive responses so far, and I'd now like to move this to the execution stage :) Sadly, I haven't found any documentation about the procedure of requesting a new extragear category. Is an online membership vote required or should I just open a sysadmin ticket? (all other steps from my proposal have a clear procedure) Best regards, Peter -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSKX7cAAoJEFCPmK2EvjqqH9gP/3ARxTyH07NCfwKiN8/thBIk pU3piAwboN2JybAEzf3puOQZXgvgo/AvNN6mZUxbkf2Z/Ea3Vd7cuNFBDFjt05TV hJUz+5afWthZw1YKQdI/r+9ZS0CPp37K3YTIfeNXuyLrXUpOsfVDxhYS3rV1bO27 k5xv0K6ZZQuUSDh7HIEaI+Se4berUM3o1p+tF0N6KXy0aLYRK/870ePd7VyapS7c TQOZbVYgeKKqrnKHCMPNH3MMFdInJTU9T4Waet2ZdvqIXv2FazFdDZjDv8XduMMG m5oK6qAjJVLT8TsVt5wzktus8fVnOR9AW2CKMgHpPhlQs26D0hiZzMlyBSd9VaW1 f8xslILer8Bviczj0em3VVqgUubKBEYtGE0AcG3GmdV+1oqvXLGUyX23trEZrUJ+ qPbO/MAwTiS4VNwh+Ms9mbVYpuIqQHWisSJrodIoRpFj4/XDhrN5NESn3ygZDiLL MB9KDS/pslfsObzk7V7mwZU8IkobWBGhGGrk+we+seDpQtpWeIDlB0sfvLS18zIk KOmoDulunZa64LADO3vUzkV818HLRJpStybIwS5uzm2LmA2q6zzeLgIev5TaEZjA DjIYDwV2tHRFstaVo+mBd70q5HduXN1uF9WBdRv9WqyceO9yS8fTGUxIZsViLoq/ /QzojSn2c/UlEMIQ7bKz =YRq8 -END PGP SIGNATURE- ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
