Re: [kde-community] Proposal: KDE Manifesto wording revision
On Wednesday 13 November 2013 20:58:46 you wrote: > Not only the “source materials” need to be accessible without additional > third party account, but everything that is needed for participation. > > Example: Let’s say KDE project KoolApp has a TODO list on a third party > website with invasive privacy policies. Then we can have two cases: > a) Developers are expected to read this TODO before doing bigger changes to > the code, so that they do not interfer with the plans of others. This would > de facto create a problematic barrier for participation (agreement to > privacy- hostile third party contracts). The wording “project asset” would > cover the case, but “source materials” would not. > b) The TODO list serves as an inoffical reminder document for the two lead I think you're correct in your observation, but I don't think it's a problem. Basically, one of the problems we had with software / project assets is actually whether it would read on todo lists on Trello, because we don't want it to, because it's too restrictive. Now, it's entirely correct that this allows projects to make todo lists hard to access and contribute to - but if they do that, they're shooting themselves into their own feet, because they're making participation in work- ing on the source materials (which the Manifesto "pro- tects") difficult. So there's already a pressure acting on projects to make todo lists easily accessible, mean- ing we IMHO don't need to regulate that behavior in the Manifesto. That doesn't mean people won't ever be stupid and try to put todo lists onto a crappy service, but then some- one will complain, and it'll hopefully get fixed. This page in the Manifesto is about the bar that pro- jects need to meet to be considered KDE projects, and I think in that context we care about the source ma- terials instead of writing down how folks must behave in the process of working on them. That's more a quest- ion of social etiquette. > Olaf Cheers, Eike ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Wednesday, November 13, 2013 21:09:28 Kevin Ottens wrote: > Seeing how the full thread developed I don't think the clause in discussion > fit for that example. It's about the online services used and governance, > not about the product (which is what this clause is about). exactly; while a valid issue, it’s a completely different issue. a topic that will probably require quite a bit more discussion and consensus building in KDE before we can probably put something in the manifesto. -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Wednesday 13 November 2013 20:58:46 Olaf Schmidt-Wischhöfer wrote: > Am Mittwoch, 13. November 2013, 18:44:45 schrieb Eike Hein: > > On Tuesday 12 November 2013 23:22:59 Thomas Pfeiffer wrote: > > > To me, "source materials" means anything that cannot be produced > > > automatically from the other source materials. > > > > > > I'd assume that when in doubt whether they should put something in the > > > repo, people would just ask. > > > > Thanks - if that's how we all intuitively read it (and I agree > > that in case of problems, it's easy to state the case for it), > > it would appear "source materials" is the way forward? > > I tested “source material” against some corner cases, and it appears to be > both too restrictive and too loose. > > Not only the “source materials” need to be accessible without additional > third party account, but everything that is needed for participation. > > Example: Let’s say KDE project KoolApp has a TODO list on a third party > website with invasive privacy policies. [...] Seeing how the full thread developed I don't think the clause in discussion fit for that example. It's about the online services used and governance, not about the product (which is what this clause is about). Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
Am Mittwoch, 13. November 2013, 18:44:45 schrieb Eike Hein: > On Tuesday 12 November 2013 23:22:59 Thomas Pfeiffer wrote: > > To me, "source materials" means anything that cannot be produced > > automatically from the other source materials. > > > > I'd assume that when in doubt whether they should put something in the > > repo, people would just ask. > > Thanks - if that's how we all intuitively read it (and I agree > that in case of problems, it's easy to state the case for it), > it would appear "source materials" is the way forward? I tested “source material” against some corner cases, and it appears to be both too restrictive and too loose. Not only the “source materials” need to be accessible without additional third party account, but everything that is needed for participation. Example: Let’s say KDE project KoolApp has a TODO list on a third party website with invasive privacy policies. Then we can have two cases: a) Developers are expected to read this TODO before doing bigger changes to the code, so that they do not interfer with the plans of others. This would de facto create a problematic barrier for participation (agreement to privacy- hostile third party contracts). The wording “project asset” would cover the case, but “source materials” would not. b) The TODO list serves as an inoffical reminder document for the two lead developers. This is not much different from a private document. This is neither a “project asset” nor a “source material”. In the case of the kde.org website, however, we do not currently allow every KDE account to make changes – but “source materials” and “project assets” clearly include PHP files. Since we already have special wording in the manifest for the website, and since private documents are not “project” material, my preliminary conclusion is that “project assets” is the best alternative of the suggested wordings – but we should still try to find something better. Olaf ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Wednesday 13 November 2013 18:44:45 Eike Hein wrote: > On Tuesday 12 November 2013 23:22:59 Thomas Pfeiffer wrote: > > To me, "source materials" means anything that cannot be produced > > automatically from the other source materials. > > > > I'd assume that when in doubt whether they should put something in the > > repo, people would just ask. > > Thanks - if that's how we all intuitively read it (and I agree > that in case of problems, it's easy to state the case for it), > it would appear "source materials" is the way forward? Sounds good to me. Changed to source materials. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Tuesday 12 November 2013 23:22:59 Thomas Pfeiffer wrote: > To me, "source materials" means anything that cannot be produced > automatically from the other source materials. > I'd assume that when in doubt whether they should put something in the repo, > people would just ask. Thanks - if that's how we all intuitively read it (and I agree that in case of problems, it's easy to state the case for it), it would appear "source materials" is the way forward? Cheers, Eike ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Tuesday 12 November 2013 23:11:54 Eike Hein wrote: > On Tuesday 12 November 2013 22:53:18 Thomas Zander wrote: > > All these may actually exclude the stuff that is used to create the > > deliverables. If you use gimp to draw, the gimp file is imporant, but the > > "asset" and "deliverable" is typically used for the png you export. > > So I'm assuming we want the source-materials, and in that case those names > > may not be the best. > > Yeah, that's exactly the problem I had with "deliverables" - > you can play the game that the deliverables of a FOSS project > *are* source materials, but sadly we just don't live in a > world where that reads intuitively ... > > > What about calling them; "source materials". Or "Product source > > materials"? > > Hmm, nice idea ... let's briefly check it against a tricky > case, though: > > - With the Oxygen icons, the original source materials are SVG > source. > - However, we also store rasterized forms in SVN. > - Those rasterized forms are often further hand-optimized, i.e. > you can't recreate trivially them from the SVG source. > > Our goal therefore must be to make sure both of these forms are > in the repo - does "source materials" apply sufficiently to "hand- > optimized PNGs cut from SVGs", or is there a loophole there? If the rasterized versions were simply the result of a script running over the source SVGs, I wouldn't call them "source materials", as they'd be more akin to compiled source code. I would consider hand-optimized PNGs as source material, though, because they were modified afterwards. If for some weird reason a project would compile their code, then go ahead and edit the binaries with a HEX editor and put those modified binaries in the release tarball, I'd expect them to put those modified binaries in the repo as well. To me, "source materials" means anything that cannot be produced automatically from the other source materials. I do agree that people might interpret "source materials" differently, though. > I toyed with variations of "source and release materials" for a > while, but that has the problems that it (a) ends up creating > loopholes for aux assets not put into tarballs in the end and > (b) can easily start reading on the tarballs themselves, becoming > confusing. > > > Let's try it out in full for now in order to keep an overview: > > "All source materials are hosted on infrastructure > available and writable by all KDE contributor accounts." > > > I think it's an improvement overall - but not sure about Oxygen. I'd assume that when in doubt whether they should put something in the repo, people would just ask. Cheers, Thomas ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Tuesday 12 November 2013 22:53:18 Thomas Zander wrote: > All these may actually exclude the stuff that is used to create the > deliverables. If you use gimp to draw, the gimp file is imporant, but the > "asset" and "deliverable" is typically used for the png you export. > So I'm assuming we want the source-materials, and in that case those names > may not be the best. Yeah, that's exactly the problem I had with "deliverables" - you can play the game that the deliverables of a FOSS project *are* source materials, but sadly we just don't live in a world where that reads intuitively ... > What about calling them; "source materials". Or "Product source materials"? Hmm, nice idea ... let's briefly check it against a tricky case, though: - With the Oxygen icons, the original source materials are SVG source. - However, we also store rasterized forms in SVN. - Those rasterized forms are often further hand-optimized, i.e. you can't recreate trivially them from the SVG source. Our goal therefore must be to make sure both of these forms are in the repo - does "source materials" apply sufficiently to "hand- optimized PNGs cut from SVGs", or is there a loophole there? I toyed with variations of "source and release materials" for a while, but that has the problems that it (a) ends up creating loopholes for aux assets not put into tarballs in the end and (b) can easily start reading on the tarballs themselves, becoming confusing. Let's try it out in full for now in order to keep an overview: "All source materials are hosted on infrastructure available and writable by all KDE contributor accounts." I think it's an improvement overall - but not sure about Oxygen. Cheers, Eike ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Tuesday 12 November 2013 21.08.21 Kevin Ottens wrote: > On Tuesday 12 November 2013 17:51:36 Eike Hein wrote: > > On Tuesday 12 November 2013 17:33:08 Aaron J. Seigo wrote: > > > if that is not clear (and apparently it is not .. you aren’t the > > > first to suggest this) then perhaps we need a phrase other than > > > “project assets” or some clarification of it. > > > > I was toying with 'deliverables', but it doesn't feel quite > > right either. Unless any of you feel that works? > > I purposefully try to stay away from discussions to avoid introducing my > own biases... But I'll make an exception for that one. > > Maybe "project" is the wrong scope indeed, it seems you guys try to say > it's the "product" which matters. So what about "product assets" > instead? All these may actually exclude the stuff that is used to create the deliverables. If you use gimp to draw, the gimp file is imporant, but the "asset" and "deliverable" is typically used for the png you export. So I'm assuming we want the source-materials, and in that case those names may not be the best. What about calling them; "source materials". Or "Product source materials"? Just thinking out loud... -- Thomas Zander ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Tuesday 12 November 2013 Aaron J. Seigo wrote: > > perhaps we’re having a definition problem here. > > to me “project assets” are all the things that make up the end > project/product as released. this is how the word is used in relation to, > for instance, games with all their data and graphics. > > TODO lists and other non-deliverables are not project assets. they are > things the project team may use, but they are not project assets. Ok, with this understanding of "project assets" it makes much more sense. So this is about the code and required data to run our products, not anything around it, which might be part of the development process, nor supplementary material like marketing material, additional documentation, web sites, etc. Maybe we should be more explicit and spell it out what it means instead of trying to find a generic term (although I kind of like Kevin's suggestion of "product assets"). We could for example say "source code and all other data, which is released as part of the project's product". -- Cornelius Schumacher ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Tuesday 12 November 2013 21:33:05 Kevin Ottens wrote:
> Hello,
>
> On Sunday 10 November 2013 21:46:41 Ingo Klöcker wrote:
> > On Sunday 10 November 2013 18:28:58 Kevin Ottens wrote:
> > > That's what this email is about, I'd like to apply the attached
> > > patch, it's mostly about small scale changes. I don't see
> > > anything which could be controversial in there.
> > >
> > > Any opinions on this? I'd like to collect feedback before
> > > proceeding
> > > with a vote of the e.V. membership and then a push.
> >
> > It's really a minor point, but I don't understand the change of
> >
> > * Stand on the shoulders of giants
> >
> > to
> >
> > * To stand on the shoulders of giants
> >
> >
> > Why does this phrase now begin with "To"+verb when all other phrases
> > (still) start with a verb without leading "To"?
>
> As Aaron noted, it makes use of an active form instead of passive. To
> be honest it's kind of subtle to me as a non-native speaker I don't
> mind either way. :-)
Same here. I don't get why "Stand" is passive since I read it as "You
stand [...]" which is active (AFAIU) while "To stand" is neither an
active form nor a passive form but the ("to" +) infinitive from. :-)
> > IMHO the leading "To" makes the phrase sound less personal. When I
> > read the other phrases I mentally add a "You" or a "You can", as in
> > "You can make use of KDE infrastructure [...]", "You benefit from
> > [...]", "You get support from [...]", etc. The leading "To"
> > prevents this.
> I don't see why the leading "To" would prevent that.
>
> Now indeed we might have inconsistencies regarding passive vs active.
> If you don't mind, I propose we ignore that point for now, and once
> we're done with this bunch of edits, we try to get a native speaker
> attached to a chair until (s)he make the pages consistent in that
> regard.
Agreed.
Regards,
Ingo
signature.asc
Description: This is a digitally signed message part.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
Hello, On Sunday 10 November 2013 21:46:41 Ingo Klöcker wrote: > On Sunday 10 November 2013 18:28:58 Kevin Ottens wrote: > > That's what this email is about, I'd like to apply the attached patch, > > it's mostly about small scale changes. I don't see anything which > > could be controversial in there. > > > > Any opinions on this? I'd like to collect feedback before proceeding > > with a vote of the e.V. membership and then a push. > > It's really a minor point, but I don't understand the change of > > * Stand on the shoulders of giants > > to > > * To stand on the shoulders of giants > > > Why does this phrase now begin with "To"+verb when all other phrases > (still) start with a verb without leading "To"? As Aaron noted, it makes use of an active form instead of passive. To be honest it's kind of subtle to me as a non-native speaker I don't mind either way. :-) > IMHO the leading "To" makes the phrase sound less personal. When I read > the other phrases I mentally add a "You" or a "You can", as in "You can > make use of KDE infrastructure [...]", "You benefit from [...]", "You > get support from [...]", etc. The leading "To" prevents this. I don't see why the leading "To" would prevent that. Now indeed we might have inconsistencies regarding passive vs active. If you don't mind, I propose we ignore that point for now, and once we're done with this bunch of edits, we try to get a native speaker attached to a chair until (s)he make the pages consistent in that regard. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision, "financial support"
On Monday 11 November 2013 22:38:21 Albert Astals Cid wrote: > El Diumenge, 10 de novembre de 2013, a les 18:28:58, Kevin Ottens va escriure: > > Hello community, > > > > Any opinions on this? I'd like to collect feedback before proceeding with > > a > > vote of the e.V. membership and then a push. > > What's the rationale in the "Be considered for financial support" -> > "Receive financial support" change? > > I mean yes, we try to suppport financially projects as much as we can, but > this sounds a bit too much as in "free money" for me :D I'd say you're reading more than there is in that change. The whole page is about potentialities, like (for instance) the announcements and promotion channels... it's clearly not automatic, need to find someone available etc. That's the same way for the financial support, need available funds in the first place. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
Hello, On Monday 11 November 2013 10:21:52 Aaron J. Seigo wrote: > On Sunday, November 10, 2013 18:28:58 Kevin Ottens wrote: > > Any opinions on this? > > second read on a monday morning: > > "Interact with teams that have common values, leadin to the > cross-pollination of ideas and innovations” > > to > > “Interaction with ...” > > since you changed “Stand on” to “To stand on”, the language is now active > rather than passive so let’s keep that consistent Applied that change. > "All KDE contributor accounts get direct (and universal) write access to the > software assets” > > to > > “All KDE contributor accounts are granted direct, universal write access to > the software assets" > > rational: removes the specialness of “universal” by putting it in brackets > (which usually means it is an afterthought or further explanation, while in > this case it is an attribute of the granting) > > also “grant” sounds less informal than “get”, but perhaps that’s just > personal taste Dropped that proposal due to the discussion in the other sub-thread. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Tuesday 12 November 2013 17:51:36 Eike Hein wrote: > On Tuesday 12 November 2013 17:33:08 Aaron J. Seigo wrote: > > if that is not clear (and apparently it is not .. you aren’t the first to > > suggest this) then perhaps we need a phrase other than “project assets” or > > some clarification of it. > > I was toying with 'deliverables', but it doesn't feel quite > right either. Unless any of you feel that works? I purposefully try to stay away from discussions to avoid introducing my own biases... But I'll make an exception for that one. Maybe "project" is the wrong scope indeed, it seems you guys try to say it's the "product" which matters. So what about "product assets" instead? My 0.02€ Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Tuesday 12 November 2013 18:00:34 Aaron J. Seigo wrote: > my concern is that if it says that all KDE contributors can write to it, it > can be interpreted as being enough to simply be able to open an account > there. > > iow, this makes github a valid place to put your code (well, if we ignore > their odd push-request driven workflow). any KDE contributor can get an > account there after all. > > imho the purpose of this particular requirement is so that anyone with a KDE > membership in hand can immediately trot over to project X and start > contributing. it is about keeping the contribution barrier low and the > shared ownership high. I agree. Basically, summing things up: We want KDE sysadmin to be the entity extending the reach of KDE contributors in a centralized fashion, rather than having it be enough for, say, an individual GitHub repo owner to grant access. The Gitorious.org scheme which we do continue to want to be open for in principle wouldn't actually have worked if sysadmin hadn't performed that function. Thus, the correct reading of "accounts" isn't to think "identity.kde.org" but more "KDE sysadmin". Then it also doesn't strictly preclude other authentication mechanisms. Given that, I agree we should keep "accounts" after all. Cheers, Eike ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Tuesday, November 12, 2013 17:44:26 Eike Hein wrote: > Deciding whether to drop or keep 'accounts' along those lines > is difficult. With previous practice, securely establishing > identity is sufficient, and the wording makes it clear that > this has to be possible for *all* contributors. That's why I > felt dropping 'accounts' might be fair game. my concern is that if it says that all KDE contributors can write to it, it can be interpreted as being enough to simply be able to open an account there. iow, this makes github a valid place to put your code (well, if we ignore their odd push-request driven workflow). any KDE contributor can get an account there after all. imho the purpose of this particular requirement is so that anyone with a KDE membership in hand can immediately trot over to project X and start contributing. it is about keeping the contribution barrier low and the shared ownership high. -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Tuesday 12 November 2013 17:33:08 Aaron J. Seigo wrote: > if that is not clear (and apparently it is not .. you aren’t the first to > suggest this) then perhaps we need a phrase other than “project assets” or > some clarification of it. I was toying with 'deliverables', but it doesn't feel quite right either. Unless any of you feel that works? Cheers, Eike ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Tuesday 12 November 2013 17:34:41 Aaron J. Seigo wrote: > +1 for getting rid of “must”; -1 on getting rid of accounts; and yes, we > probably need to find some better wording for “project assets” since it > trips people up. On the accounts one, after hitting send I was back to pondering, about that, too ... it's a question of what we're after, conven- ience, extending the chain of trust, or both. For example, when we were trying to expand into Gitorious.org for hosting, people had to sign up with Gitorious on their own, and then there was a separate verification step where sysadmin interacted with the account holder to verify their identity and establish a mapping between a KDE SVN account and a Gitorious account, extending the chain of trust and subsequently allowing the Gitorious account to write to KDE repositories on Gitorious. When the Manifesto was crafted, several people felt it was im- portant that we stay open to experiments of this sort, and not codify implementation. I.e. "access needs to be there, and making it happen is ultimately up to the sysadmin team (and at their discretion given resources), but how the happening looks like should not be defined". Deciding whether to drop or keep 'accounts' along those lines is difficult. With previous practice, securely establishing identity is sufficient, and the wording makes it clear that this has to be possible for *all* contributors. That's why I felt dropping 'accounts' might be fair game. OTOH, the Gitorious.org scheme was also a big hassle and a resource drain, and ultimately one of the reasons that contri- buted to the decision to abandon Gitorious.org and self-host. But perhaps this is exactly why accounts doesn't need to be specified: Since it's a hassle, there's already pressure not to do it, there's already a force causing sysadmin to say 'no, we can't reasonably do this', and we've seen both happen. Cheers, Eike ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Tuesday, November 12, 2013 17:06:51 Eike Hein wrote: > - "Must" is gone. It's kinda feels more declarative now! > - "Accounts" is gone. > > Open issues: > - Do we need to do anything about "project assets"? +1 for getting rid of “must”; -1 on getting rid of accounts; and yes, we probably need to find some better wording for “project assets” since it trips people up. also: “available to and writable by” is probably more grammatically correct. nothing meaning changing, just an editorial note :) -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Tuesday, November 12, 2013 16:43:27 Cornelius Schumacher wrote: > It also sounds like it would rule out using any other tools, which are not > hosted on KDE infrastructure. In the IRC log there were mentioned Google > Docs, Trello, there are certainly more (and not only closed-source ones). I > don't think we are trying to say that, as that would obviously go against > the status quo, and the manifest is supposed to document our current view, > not a future goal. what project assets are hosted on google docs, trello, etc? perhaps we’re having a definition problem here. to me “project assets” are all the things that make up the end project/product as released. this is how the word is used in relation to, for instance, games with all their data and graphics. TODO lists and other non-deliverables are not project assets. they are things the project team may use, but they are not project assets. it is very problematic to include things like TODO lists in there since a developer may keep a TODO list, meeting notes or other things related to projects entirely on a local disk. what then? no, this should only be about what is delivered as part of the project’s product itself. if that is not clear (and apparently it is not .. you aren’t the first to suggest this) then perhaps we need a phrase other than “project assets” or some clarification of it. > > * Hosting location is still not nailed down further than "KDE > > > > contributor accounts must have r/w access", answering a de- > > mand in the original Manifesto discussion. > > I guess the reason why I'm perceiving this as excluding non-KDE hosted > infrastructure is that I read "KDE contributor accounts must have r/w > access" as "I must be able to log in with identity.kde.org". That's > obviously not possible with many services hosted by other parties. that's precisely the point: to ensure that if you have a KDE contributor account that you can then use that account to change assets. -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Tuesday 12 November 2013 16:43:27 Cornelius Schumacher wrote: > When I read the suggestion and this explanation I wonder why we don't just > say what is meant: "The canonical version of the project is hosted on KDE > infrastructure"? > > This doesn't cover the part that all KDE contributors have write access to > all projects, but that would be covered by the original proposal of “All > KDE contributor accounts are granted direct, universal write access to the > software assets" tl;dr: Explanations, acknowledgements; new proposal at the bottom. I'd basically like to kill two birds with one stone and define KDE infrastructure as "infrastructure accessible and writable to KDE contributor [accounts]" (brackets: see further down). I feel that obviates the need for a separate definition; it documents the bar infra needs to meet to be considered "KDE in- frastructure" for the purpose of the bullet. The problem I see with "The canonical version is hosted" is the following: It's the goal we have in mind, but it doesn't aid in implementing that goal. I feel the Principles section of the Manifesto is less a collection of statements of intent, but rather more practical than that. The reason I feel it doesn't aid implementation is because it gives too much leeway in the interpretation of "canonical". For example, someone could interpret it as allowing the hosting of auxiliary assets (say, scripts or utility programs) in locations that don't meet the infra bar, causing spread, and possibly causing the canonical location to drift as a result. The proposed wording is explicit about *all* assets needing to be hosted on infra meeting the bar. I feel that "canonical" just goes a bit too far in terms of vagueness. > I'll give you my feedback here, from when I read the proposed wording for > the first time: I perceived it as off-putting, because it says "all" and it > says "must". That feels as a pretty scary statement to me, especially > looking from the perspective of someone trying to move closer to KDE, but > not being there yet. I'm not sure what we can do about the "All", because I think both instances are very vital to what the bullet wants to accomplish. I also don't personally feel that it's off-putt- ing because it's inclusionary. OTOH, the "must" is strong, and we can possibly do without. > It also sounds like it would rule out using any other tools, which are not > hosted on KDE infrastructure. In the IRC log there were mentioned Google > Docs, Trello, there are certainly more (and not only closed-source ones). I > don't think we are trying to say that, as that would obviously go against > the status quo, and the manifest is supposed to document our current view, > not a future goal. In the IRC log, I voiced the concern that using "project assets" rather than "software assets" could be read as disallowing the use of e.g. Trello for project to do lists. In the end, for the proposal, we made the decision that "software assets" being misunderstood as referring only to code was the bigger concern, but I do think the other con- cern is valid as well. Aaron's take on this was that he doesn't feel "assets" inherently covers the use of services. > I guess the reason why I'm perceiving this as excluding non-KDE hosted > infrastructure is that I read "KDE contributor accounts must have r/w > access" as "I must be able to log in with identity.kde.org". That's > obviously not possible with many services hosted by other parties. Excellent point, perhaps we could address this by removing "accounts"? The key interest is that the same *people* have access; the authentication mechanism is indeed an implemen- tation detail. Here's a new version: "All project assets are hosted on infrastructure available and writable to all KDE contributors." Changelog: - "Must" is gone. It's kinda feels more declarative now! - "Accounts" is gone. Open issues: - Do we need to do anything about "project assets"? Cheers, Eike ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Monday 11 November 2013 13:56:32 Eike Hein wrote: > > After the exchanges in this and the other leg of the subthread > there ended up being a follow-up discussion on IRC, with Aaron, > Sune (svuorela), me (Sho_) and others contributing. > > Ultimately, we've together settled on this wording suggestion: > > "All project assets must be hosted on infrastructure available > and writable to all KDE contributor accounts." Thanks for the nice progress and the good discussion. > Summing up the thoughts behind this: > > * This is intended to cover the ideas behind both the original > ALL and ONLY clauses by specifying that 'all project assets' > must be on infrastructure that's covered by our contributor > account system. The way this implements ONLY is by implicitly > ruling out mirrors that contain additional assets - in other > words, it's meant to ensure that KDE's repositories are ca- > nonical for projects, and not outdated. This brings parity > between what ReviewBoard is doing and what a GitHub mirror > is doing. When I read the suggestion and this explanation I wonder why we don't just say what is meant: "The canonical version of the project is hosted on KDE infrastructure"? This doesn't cover the part that all KDE contributors have write access to all projects, but that would be covered by the original proposal of “All KDE contributor accounts are granted direct, universal write access to the software assets" > * The new wording hopefully succeeds in being less off-putting > to readers, to avoid defeating the purpose of the original > ONLY cause (i.e. we want to successfully pitch/convince > people to be part of the community, not appear to force them). I'll give you my feedback here, from when I read the proposed wording for the first time: I perceived it as off-putting, because it says "all" and it says "must". That feels as a pretty scary statement to me, especially looking from the perspective of someone trying to move closer to KDE, but not being there yet. It also sounds like it would rule out using any other tools, which are not hosted on KDE infrastructure. In the IRC log there were mentioned Google Docs, Trello, there are certainly more (and not only closed-source ones). I don't think we are trying to say that, as that would obviously go against the status quo, and the manifest is supposed to document our current view, not a future goal. Maybe that's not what's meant as you explain in the paragraph below, but it isn't obvious to me from just reading the suggested wording. Could be that it's just me, though ;-) > * Hosting location is still not nailed down further than "KDE > contributor accounts must have r/w access", answering a de- > mand in the original Manifesto discussion. I guess the reason why I'm perceiving this as excluding non-KDE hosted infrastructure is that I read "KDE contributor accounts must have r/w access" as "I must be able to log in with identity.kde.org". That's obviously not possible with many services hosted by other parties. -- Cornelius Schumacher ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Tuesday 12 November 2013 02:43:39 Valorie Zimmerman wrote: > This makes me so happy. I've been through various "by-law fights" in > the past, which sometimes exhaust or even break apart groups. Instead, > I see us really grappling with our shared values, strengths and > weaknesses, and putting them together in a really clear, evolving > document. > > My compliments to everyone for fighting fair, holding out for your > values, and seeing it through to a good conclusion. This is what good > dialogue is: thinking together. Replying again feels a bit like I need to have the last word, so, sorry for that & not the case, but I think a little post-mortem talk never hurts, especially if we are talking about a successful outcome ... :) What tends to go through my head a lot is: The absolute best for KDE's success is when the people who like to do work in KDE manage to work together, because we can't do it alone. That's an overriding concern. Winning an argu- ment doesn't accomplish that goal when it drives someone else away. Quitting because other folks have a slightly different idea does nothing to accomplish that goal either (especially when their basic motivation is compatible). Both make a big case for staying flexible as a discussion evolves, and it gets a chance to possibly produce a result that's superior to the initial starting positions of every- one. A tricky bit with that, though: You have to be flexible, but also trust that the other side will be flexible as well. Most people do re-examine and re-test their points as they state them, and most of us are ethically rigorous enough to change our minds based on new information. > Valorie Cheers, Eike ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Mon, Nov 11, 2013 at 5:34 AM, Eike Hein wrote: > On Monday 11 November 2013 14:25:32 Kevin Ottens wrote: >> I'd like to note I'm glad that you all took the time to resolve this issue >> by using a better medium than email. Thanks for that, less time spent >> tracking emails and ideas back and forth for me. > > Definitely helped; hopefully providing the log also manages > to strike the right balance in terms of transparency of the > process. > > >> Thanks again for the progress made on that point. > > Agreed - assuming everyone else likes the proposal as well, > it was really nice to see that we can discuss something as > fundamental as productively, and respect and integrate our > concerns as a result. > > Working processes to refine and adapt the Manifesto are an > important component to making the Manifesto work, so hope- > fully we manage to keep that up. > > >> Cheers. > > Cheers, > Eike This makes me so happy. I've been through various "by-law fights" in the past, which sometimes exhaust or even break apart groups. Instead, I see us really grappling with our shared values, strengths and weaknesses, and putting them together in a really clear, evolving document. My compliments to everyone for fighting fair, holding out for your values, and seeing it through to a good conclusion. This is what good dialogue is: thinking together. Valorie ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision, "financial support"
El Diumenge, 10 de novembre de 2013, a les 18:28:58, Kevin Ottens va escriure: > Hello community, > > Any opinions on this? I'd like to collect feedback before proceeding with a > vote of the e.V. membership and then a push. What's the rationale in the "Be considered for financial support" -> "Receive financial support" change? I mean yes, we try to suppport financially projects as much as we can, but this sounds a bit too much as in "free money" for me :D Cheers, Albert > Regards. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Monday 11 November 2013 14:25:32 Kevin Ottens wrote: > I'd like to note I'm glad that you all took the time to resolve this issue > by using a better medium than email. Thanks for that, less time spent > tracking emails and ideas back and forth for me. Definitely helped; hopefully providing the log also manages to strike the right balance in terms of transparency of the process. > Thanks again for the progress made on that point. Agreed - assuming everyone else likes the proposal as well, it was really nice to see that we can discuss something as fundamental as productively, and respect and integrate our concerns as a result. Working processes to refine and adapt the Manifesto are an important component to making the Manifesto work, so hope- fully we manage to keep that up. > Cheers. Cheers, Eike ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
Hello, On Monday 11 November 2013 13:56:32 Eike Hein wrote: > After the exchanges in this and the other leg of the subthread > there ended up being a follow-up discussion on IRC, with Aaron, > Sune (svuorela), me (Sho_) and others contributing. I'd like to note I'm glad that you all took the time to resolve this issue by using a better medium than email. Thanks for that, less time spent tracking emails and ideas back and forth for me. > Ultimately, we've together settled on this wording suggestion: > > "All project assets must be hosted on infrastructure available > and writable to all KDE contributor accounts." After reading the thread, the IRC log and this proposal, I think it's a clear improvement. I integrated this change locally. Thanks again for the progress made on that point. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
Heyo ... After the exchanges in this and the other leg of the subthread there ended up being a follow-up discussion on IRC, with Aaron, Sune (svuorela), me (Sho_) and others contributing. Ultimately, we've together settled on this wording suggestion: "All project assets must be hosted on infrastructure available and writable to all KDE contributor accounts." Summing up the thoughts behind this: * This is intended to cover the ideas behind both the original ALL and ONLY clauses by specifying that 'all project assets' must be on infrastructure that's covered by our contributor account system. The way this implements ONLY is by implicitly ruling out mirrors that contain additional assets - in other words, it's meant to ensure that KDE's repositories are ca- nonical for projects, and not outdated. This brings parity between what ReviewBoard is doing and what a GitHub mirror is doing. * The new wording hopefully succeeds in being less off-putting to readers, to avoid defeating the purpose of the original ONLY cause (i.e. we want to successfully pitch/convince people to be part of the community, not appear to force them). * Hosting location is still not nailed down further than "KDE contributor accounts must have r/w access", answering a de- mand in the original Manifesto discussion. * "Software assets" changed to "project assets", with Aaron acting as a test case for folks having an easier time under- standing that this also covers e.g. the Oxygen icons project. The full log of the conversation is attached, with unrelated conversation and names stripped as requested (topic-unrelated reason). Cheers, Eike previous discussions about the manifesto .. well, the manifesto is a living document, and there will be new people who come to it the manifesto is unlikely to survive if it requires in any way prior knowledge of private discussion it is similarly unlikely to "live" if it requires knowledge of prior discussion (public or not) a successful document of this sort is self documenting, and where there is territory to be covered that can not be self-documenting in such a fashion, it is territory best left untrod btw, i heard about the extensive discussion through others, but was not part of it myself; i was taking a haiatus from kde, something things such as manifesto helped to end .. so the theory of 'new voices' is practical rather than theoretical, even if the 'new voices' are 'old voices' within kde whoops, I had my notifications for this channel disabled ... to cc my reply from #plasma: ah, and i should probably note that it is not necessary to know all the discussion that leads up to a given part of the manifesto ... [12:21] aseigo: my point with that is just that the manifesto is designed to be a cache of previous discussions, so diffs to it need to be argued with "why this is better" than "let's discuss from scratch" usually imho [12:21] aseigo: but it's difficult to balance people's needs to go back to the root of an issue with trying to avoid churn / maintain consensus .. rather that the manifesto itself should be understandable without that i.e. basically I totally agree ... it's also unfortunate that the previous discussion was on the ev list and now we have the k-c list with a wider audience so yeah, i agree it's a reasonable concern and i don't mind debating things with friendly folks anyway ;) mm.. see, i'm not sure we acdtually agree fully here. the manifesto is not a "cache of previous discussions" imho it is the *result* of previous discussions but it is not the record of them, not even in cache form that is more important than it may seem; if the manifesto is not self-documenting then we get the kind of legalistic and difficult to understand (and therefore implement) language in the ONLY / ALL clause aseigo: What I mean is that when we're faced with a decision, we can base the discussion that goes into making that decision on the Manifesto instead of aseigo: It's a discussion aid, it provides a starting point and i guarantee you that in 5 years time, all discussion that led to that language will be *lost* yes, it is a touchstone document aseigo: Yes, but ... that's exactly why I feel it's important to be explicit in the manifesto aseigo: If we lose the ONLY, we've lost a part of the Manifesto's utility even if that ecplicit language fails? again, i think you expect things from the manifesto that it can not deliver aseigo: It explicitly affects policy decisions we make frequently (e.g. Albert and I just this month talked with the Kst maintainers but making Kst manifesto-compliant again, and as a result of that it's getting back to having a master repo on git.kde.org) if we couldn't have pointed the Kst dudes to the Manifesto, .. so I'm not argueing theoretical concerns here This is practical stuff if i'm honest, i find coercing people back to git.kde.org to toe a legalistic line to be less than forth
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Monday, November 11, 2013 11:46:20 Eike Hein wrote: > * Improves the situation. a) by removing language whose literal wording creates an us/them wall, something that is the opposite of inclusion. b) by replacing it with something that is clearer to understand on first read as has been noted elsewhere, this document is used not only by us but also by people currently not part of KDE to determine whether they would want to be or not. do we really wish to paint an “us/them” picture? does legalistic language (ONLY versus ALL) belong in such a gateway document? you are focused on creating gateways into the KDE community, and that is awesome. the Manifesto is such a gateway in itself. it not only codifies the creation of other gateways, it *is* a gateway. additionally, the Manifesto is also a form of security for those already *in* the KDE community: the more forthright and clear it is, the less it looks like it was written by lawers, the better. the Manifesto is not simply about recruitment; in fact I would suggest that it is even more useful as a means of participant retention. so while i agree with your desire to keep the gateway to contributors via the patch-then-get-an-account method, the Manifesto document is not the right place for this particular approach. > * My concerns are not warranted? it isn’t that your concerns are not warranted, it’s that the concerns you have are out of scope for this kind of document. “what are the pathways / gateways to contributor recruitment” can never be appropriately covered in the Manifesto. if anything, they require treatment in a document of its own. > So far all I understood is "proxying changes still results in > code getting in, so the 'direct' in 'direct write access' > doesn't matter", which I think is an angle that completely > ignores the psychological side of things. it helps if we keep things in context. there are two effects the Manifesto wording has: * the literal: which is what people will reference and follow. if that wording leads to nonsensical results then the Manifesto is not useful as it requires additional (and non-obvious) interpretation. the reason i pointed out the proxying changes issue is that it demonstrates how the literal wording is broken in that it *does not reflect accurately what KDE does right now* * the social engineering aspect. the ‘proxying changes’ thing does not touch on this in the least. while i understand there are psychological aspects to this, i’m also offering a broader view that includes the intended social consequences as well as the impact of the actual wording as written in the Manifesto. we can cover both; in fact, we must. -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Monday, November 11, 2013 11:18:34 Eike Hein wrote: > By disallowing direct write access for folks without a KDE > contributor account, we're making them get KDE contributor > accounts to gain write access. This ends up happening as a > natural result of the tedium involved with proxying changes, > and once they've got their accounts, there are few-to-no > barriers between them and diversifying into other KDE pro- > jects. Meanwhile, because everyone's been through the same > process to get that account, this can work in terms of trust. i fail to see how the ONLY clause addresses that in the least. > I think you're locked into the idea "Eike and his ilk are > just scared of the barbarians at the gates, this is classic > tribalism!”, not at all; my concern is that is that literal wording in the manifesto describes a “barbarians at the gates” mentality. you may not have that in mind, but that’s what it states. it is so awkward that i honestly can not show it to people without them frowning to figure out just what the heck they read or me having to explain why it is so awkward. i don’t think the ONLY clause inevitably leads to what you are hoping for, there are other methods people come into KDE by and emphasizing this particular one in such a manner within the Manifesto makes it incomplete. i totally get what the language is trying to do from a social engineering perspective. i think we can do better than that wording, however. > but my actual evil plan is to turn the, eh, > barbarians at the gates into folks who accept responsibi- > lity in KDE. Because I've *seen it work*. i’m not disagreeing with that model. what i’m trying to point out is that the ONLY clause does nothing to help with that. what it did do was make the manifesto sound ham-fisted and awkward. it may make sense to you, but it’s actually quite opaque. an obfuscated (intentionally or not) manifesto will only lead to it being poorly implemented at best and at worst worked against. you’ve spent several emails explaining what you want to cause. i think we all agree that the “get more people in the KDE community” goal, along with the methodology you describe, is a good thing. what i’d prefer to discuss is: * how the ONLY clause will actually work * how we can open entry gateways using the manifesto that are more broadly encompassing as well as clearer in the formation -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Monday 11 November 2013 11:12:12 Aaron J. Seigo wrote: > so if the ONLY clause was somehow intended to address the “second class > citizen” issue, it should be evident how it can not do so in its current > form and also remain consistent with KDE’s current, consensus culture. It's not evident to me. Here's my approach to this. I'm thinking about and doing soul- searching on: * How did Aaron Seigo-of-KDE become Aaron Seigo-of-KDE? * How did I get from submitting a ten-line patch to Konversation to becoming its maintainer later on, and going beyond Konver- sation to contributing to other KDE projects, becoming an e.V. member, all that good stuff that's been a lot of fun. * I made most of KDE's new contributor accounts for I think about a one to one-and-a-half year stretch somewhere in 2010-2012. As in, during that time, for most of those cases I acted as the glue between KDE, the contributor and their supporters. I evolved some aspects of the process and wrote some of the documents we still send to the involved parties. So I've seen plenty of why people want to get an account, how they got in touch with KDE in the first place, and where they wanted to go from there. Fortunately, I think we have plenty of success stories. I think we're doing a lot better than many other FOSS communities, which often fizzle-out with their original developer generation or don't grow into areas they could be rocking. Or fragment. We've been around for close to two decades, we're still productive, we're still doing new things. Clearly, we're doing some things right. So I'm wondering: * What do our contributor success stories have in common? * What of our established practices helped things along? * What was critical to enabling folks to do these things? The stuff I wrote is what I walked away with and what my current thinking on the matter is. It's not static; I'm open to attempts to enhance my understanding. So, can you explain to me (again, perhaps?) why this change: * Improves the situation. * My concerns are not warranted? So far all I understood is "proxying changes still results in code getting in, so the 'direct' in 'direct write access' doesn't matter", which I think is an angle that completely ignores the psychological side of things. Cheers, Eike ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Monday 11 November 2013 10:54:52 Aaron J. Seigo wrote: > iow, it has solved nothing. No, I believe you're actually overlooking a broader point here. Codifying the access model is a lot less about actual ACL, and more about the implications it has for *people*, both existing contributors, but also *new* contributors. By disallowing direct write access for folks without a KDE contributor account, we're making them get KDE contributor accounts to gain write access. This ends up happening as a natural result of the tedium involved with proxying changes, and once they've got their accounts, there are few-to-no barriers between them and diversifying into other KDE pro- jects. Meanwhile, because everyone's been through the same process to get that account, this can work in terms of trust. I think you're locked into the idea "Eike and his ilk are just scared of the barbarians at the gates, this is classic tribalism!", but my actual evil plan is to turn the, eh, barbarians at the gates into folks who accept responsibi- lity in KDE. Because I've *seen it work*. It's not that removing this restriction is bad just for existing contributors, I think it's bad for new contri- butors that start contributing to KDE without an incen- tive or vector to get a KDE contributor account. Cheers, Eike ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Monday, November 11, 2013 10:56:11 Eike Hein wrote: > On Monday 11 November 2013 10:29:07 Aaron J. Seigo wrote: > > i’ll also point out that we already have a tiered system: maintainers. > > Psychology matters. It's a lot easier to step up to become a right, so not all tiered systems are bad. it depends on the implementation of them and what the resulting attributes are due to that implementation. ergo concern about “second class citizens” is unwaranted and in fact goes against healthy and well-formed processes we already see in KDE. so if the ONLY clause was somehow intended to address the “second class citizen” issue, it should be evident how it can not do so in its current form and also remain consistent with KDE’s current, consensus culture. -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Monday, November 11, 2013 10:44:46 Eike Hein wrote: > On Monday 11 November 2013 10:14:56 Aaron J. Seigo wrote: > > the difference is that it does not specify “ONLY”, which in this day and > > age of decentralized revision control systems seems sensible. or are you > > suggesting that we should not allow any contributions from the “outside”? > > You're confusing direct write access with contributing. We > have several means to accept contributions from the "out- > side" that don't require the former, e.g. ReviewBoard. ha. i just wrote an email noting this as well. fun. it is exactly this point about contribution vs write access that makes the entire “ONLY” clause useless. > > not only is the new language clearer thanks to removing 2 lines and one > > indented list, it makes the manifesto sound a lot less like it was put > > together by pedants: ONLY and ALL .. really? > > The purpose of the Manifesto is to codify established practice > and important, long-held ideas of the community in order to > act as a cache that aids us in making future discussions. To agreed. i have been making that exact argument for goodness how many years :) > that end, we had a long discussion process that produced a con- > sensus that was put in writing. The "burden of proof" is there- > fore on change proposals, and changes in intended meaning > should be argued a lot better than "the current wording does > not soothe my eyes" and with spikes like "really?". great; please respond to my other email. -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Monday 11 November 2013 10:29:07 Aaron J. Seigo wrote: > i’ll also point out that we already have a tiered system: maintainers. Psychology matters. It's a lot easier to step up to become a maintainer if the number of process barriers is low, when the access model informs you of your basic right to grow in that direction, and when you have examples of others having taken this step while working within the same system and structure - if the access model diversifies from project to project, that last part breaks down, too. Take that from someone who became the maintainer of a KDE pro- ject within about a year of getting a contributor account and wound up maintaining several projects within the community. We need to think about the future. Aaron Seigo won't be around working on KDE forever, unfortunately. Nor will I. I'd like to make sure we have replacements. Cheers, Eike ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Monday, November 11, 2013 10:34:09 Eike Hein wrote: > There's two halves to the access model: > > * All KDE contributor accounts must have direct write access. (There we all agree on this point, it is therefore unnecessary to go into this further. it is the ONLY clause: > * Only KDE contributor accounts may have direct write access. That > means if your code is in a place that in theory allows giving > others access, you're not allowed to do so. this is unenforceable, and probably not even measurable. again, we can observe that by examining it in terms of being a tautology: only people with direct write access to git.kde.org can change the code on git.kde.org. (repeat for any other kde hosted service) if there was a theoretical repository on git-hub for the (also theoretical) kde-foo project, writes to that repository could still not find their way into git.kde.org unless somone with write access pushes it there. this is, in fact, exactly what we do every single day on reviewboard.kde.org: we proxy changes for others. so: “if your code is in a place that in theory allows giving others access” becomes “if your code is in place that in theory allows giving others access, that code still requires a KDE contributor account to approve of those changes before they reach git.kde.org. therefore, if your code is in a place that in theory allows giving others access, only KDE contributors accounts may have direct write access to the git.kde.org repository.” iow, it has solved nothing. worse, if we actually were to try and enforce this in a meaningful fashion, it could only be done in a way that would interfere with reviewboard and similar patch review systems. perhaps what you are trying to say is: the canonical version of the project is hosted on KDE infrastructure now *that* makes sense because it means that to be a KDE project then it must be hosted within the KDE infrastructure .. which in turn means that for any contributions to make it into the canonical version of that project which come from by means other than direct access must be approved by a KDE contributor account. -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Monday 11 November 2013 10:14:56 Aaron J. Seigo wrote: > the difference is that it does not specify “ONLY”, which in this day and age > of decentralized revision control systems seems sensible. or are you > suggesting that we should not allow any contributions from the "outside"? You're confusing direct write access with contributing. We have several means to accept contributions from the "out- side" that don't require the former, e.g. ReviewBoard. > not only is the new language clearer thanks to removing 2 lines and one > indented list, it makes the manifesto sound a lot less like it was put > together by pedants: ONLY and ALL .. really? The purpose of the Manifesto is to codify established practice and important, long-held ideas of the community in order to act as a cache that aids us in making future discussions. To that end, we had a long discussion process that produced a con- sensus that was put in writing. The "burden of proof" is there- fore on change proposals, and changes in intended meaning should be argued a lot better than "the current wording does not soothe my eyes" and with spikes like "really?". Cheers, Eike ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Monday 11 November 2013 10:10:56 Thomas Zander wrote: > Could you please explain to those that don't immediately spot it how the > before and after are functionally different? Of course. There's two halves to the access model: * All KDE contributor accounts must have direct write access. (There is some debate about this wrt/ what it means to review processes, so think about this in terms of technical means, not the social etiquette around committing.) That means it's not allowed to host your code at some place that wasn't enabled for this. git.kde.org is an example of infrastructure that is enabled for this access. For a while, we enabled Gitorious.org. * Only KDE contributor accounts may have direct write access. That means if your code is in a place that in theory allows giving others access, you're not allowed to do so. The former does not imply the latter, and it doesn't do it in prac- tice. We currently have several KDE projects that mirror to GitHub and accept code contributions via pull requests there for example, but under the Manifesto aren't allowed to provide direct write access to the GitHub repository to folks not holding a KDE contri- butor account. None of us like restricting freedoms. We tend to react negatively to the phrase "not allowed", and to those who use it, even if that use is the result of a collaborative consensus. So I understand and am prepared to reiterate the reasons for these restrictions again and again: * There is significant trust placed in the process that contri- butors undergo to get their contributor account. It's a process based on peer review and a process that tries to ensure a cer- tain level of familiarity with the rules and workflows of the community. If you can be sure that the new contributor who has started committing to your codebase underwent this process, it tends to alter how you engage with them - both the respect you have for his right to do so, the expectations you have for how he goes about it, and the level of trust you bring with you into conflict resolution, for example. * The process also works to emancipate new contributors. The broad, equal write access - granted at a time when familiarity with the social etiquette build on top of it is hopefully also in place - should signal equality between contributors and en- courage accepting additional responsibility. There's a lot less friction in becoming a maintainer or simply performing maintain- er-like actions on an unloved piece of code if there are no additional bars to meet. These ideas end up reinforcing each other in a number of ways. If the access model allows everyone broad access, you need broad trust. If you want people to give the freedom to expand in their role and implement things like shared ownership, you need broad access. And so on. I think that this wording change is an accident because the original language seems to do poorly at getting these points across. Cheers, Eike ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Monday, November 11, 2013 09:16:24 Sune Vuorela wrote: > On 2013-11-11, Thomas Zander wrote: > > Could you please explain to those that don't immediately spot it how the > > before and after are functionally different? > That it opens up for several groups of contributors, KDE contributors and > other people. I do also think that it is important that KDE projects has > KDE contributors as their only citizens, so that there isn't some being > second class citizen. this last sentence is self-contradictory, not to mention tautological. contradiction: if a KDE project only has KDE contributors as their “citizens”, then everyone who is not a KDE contributors is by definition a second-class citizen (if at all) tautology: a KDE contributor is someone who is a “citizen” of a KDE project. this makes the sentence equivalent to “it is important that KDE projects have KDE contributors as their only KDE contributors” or “it is important that KDE projects have their citizens as their only citizens” i’ll also point out that we already have a tiered system: maintainers. if those of you concerned about multiple tiers of “citizens” could enumerate the exact and specific concerns, such as what a “second class citizen” might look like, then we can check both those assumptions and the language to ensure that this is covered appropriately. my suspicion is that if there is a valid concern here, it belongs in the definition of what a KDE contributor account is, not how those accounts apply to an individual project. -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Sunday, November 10, 2013 18:28:58 Kevin Ottens wrote: > Any opinions on this? second read on a monday morning: "Interact with teams that have common values, leadin to the cross-pollination of ideas and innovations” to “Interaction with ...” since you changed “Stand on” to “To stand on”, the language is now active rather than passive so let’s keep that consistent "All KDE contributor accounts get direct (and universal) write access to the software assets” to “All KDE contributor accounts are granted direct, universal write access to the software assets" rational: removes the specialness of “universal” by putting it in brackets (which usually means it is an afterthought or further explanation, while in this case it is an attribute of the granting) also “grant” sounds less informal than “get”, but perhaps that’s just personal taste -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On 2013-11-11, Thomas Zander wrote: > Could you please explain to those that don't immediately spot it how the > before and after are functionally different? That it opens up for several groups of contributors, KDE contributors and other people. I do also think that it is important that KDE projects has KDE contributors as their only citizens, so that there isn't some being second class citizen. /Sune ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Monday, November 11, 2013 07:31:15 Eike Hein wrote: > In my mind - based on experience as contributor, main- > tainer and for a period, sysadmin working on the contri- > butor account system - codifying the two halves that make > up our access model was the single most important accom- > plishment of the Manifesto process. two halves? i think that’s an overstatement. the first statement says: ONLY KDE accounts get write access to software assets the second statement says: ALL KDE accounts get write access to software assets so ONLY *and* ALL. iow, we’re exclusionary. the new proposed language is: ALL KDE accounts get direct, universal write access to the software assets the difference is that it does not specify “ONLY”, which in this day and age of decentralized revision control systems seems sensible. or are you suggesting that we should not allow any contributions from the "outside"? not only is the new language clearer thanks to removing 2 lines and one indented list, it makes the manifesto sound a lot less like it was put together by pedants: ONLY and ALL .. really? -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Monday 11 November 2013 07.31.15 Eike Hein wrote: > - * Software assets access model > -* Direct write access to the software assets is granted only to KDE > contributor accounts > -* Direct write access to the software assets is granted to all KDE > contributor accounts > + * All KDE contributor accounts get direct (and universal) write access to > the software assets --- > What's the motivation for this change? Unwieldy lang- > uage? Then let's make it more elegant. But let's not > lose the meaning in the process, because _this stuff be > important_. Could you please explain to those that don't immediately spot it how the before and after are functionally different? -- Thomas ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
> - * Software assets access model > -* Direct write access to the software assets is granted only to KDE contributor accounts > -* Direct write access to the software assets is granted to all KDE contributor accounts > + * All KDE contributor accounts get direct (and universal) write access to the software assets Wow - I struggle to put into words how much I am opposed to this change. I just jumped up from the breakfast table with breakfast uneaten in order to get to a keyboard as fast as I could. In my mind - based on experience as contributor, main- tainer and for a period, sysadmin working on the contri- butor account system - codifying the two halves that make up our access model was the single most important accom- plishment of the Manifesto process. The access model is the basis for the trust dynamics, shared ownership, shared responsibility and generally contributor equality in our community. I believe it's the key to why KDE, unlike many other FOSS communities, has managed to become multi-generational, and I'd like it to continue. Quite a lot on the first page of the Manifesto flows from those two lines. I urge everyone who can to go back to the original Mani- festo discussions, where this was discussed at length. What's the motivation for this change? Unwieldy lang- uage? Then let's make it more elegant. But let's not lose the meaning in the process, because _this stuff be important_. Cheers, Eike ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Sunday 10 November 2013 18:28:58 Kevin Ottens wrote: > That's what this email is about, I'd like to apply the attached patch, > it's mostly about small scale changes. I don't see anything which > could be controversial in there. > > Any opinions on this? I'd like to collect feedback before proceeding > with a vote of the e.V. membership and then a push. It's really a minor point, but I don't understand the change of * Stand on the shoulders of giants to * To stand on the shoulders of giants Why does this phrase now begin with "To"+verb when all other phrases (still) start with a verb without leading "To"? IMHO the leading "To" makes the phrase sound less personal. When I read the other phrases I mentally add a "You" or a "You can", as in "You can make use of KDE infrastructure [...]", "You benefit from [...]", "You get support from [...]", etc. The leading "To" prevents this. Other than that the changes look good. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Sunday, November 10, 2013 18:51:06 Kevin Ottens wrote: > On Sunday 10 November 2013 18:45:42 Marta Rybczynska wrote: > > leadin -> leading > > Great, I managed to introduce a typo... Thanks for spotting it. It's fixed you just wanted to see if we were actually reading it ;) other than the typo, and including David E.’s input: +1 from me cheers ... -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Sunday 10 November 2013 19:03:45 David Edmundson wrote: > There's a change from > > "_can_ be defended via the FLA" > to > "_will_ be protected defended via the FLA" > > (emphasis added by me) > > As I understand it the FLA is opt in (http://ev.kde.org/rules/fla.php) > and does not automatically cover all projects. Which makes it a "can" indeed. Changed back to "can", kept the rest of the change. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Sunday, November 10, 2013 18:28 Kevin Ottens wrote: > Hello community, > > After the publication of the initial version of the manifesto, I said I'd > act as curator for the time being and that it should be a living document > which would get updated from time to time. > > I didn't really live up to it so far as no revision has been done. But > somehow I found a small chunk of time today and decided to use it to > prepare a new revision. > > As a matter of fact, I got some feedback from people. Some of the items are > rather large (and I'll send separate emails for those), but there was a > collection of nice wording simplifications. > > That's what this email is about, I'd like to apply the attached patch, it's > mostly about small scale changes. I don't see anything which could be > controversial in there. > > Any opinions on this? I'd like to collect feedback before proceeding with a > vote of the e.V. membership and then a push. > > Regards. I support the changes. Carl ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
There's a change from "_can_ be defended via the FLA" to "_will_ be protected defended via the FLA" (emphasis added by me) As I understand it the FLA is opt in (http://ev.kde.org/rules/fla.php) and does not automatically cover all projects. David ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Sunday 10 November 2013 18:45:42 Marta Rybczynska wrote: > leadin -> leading Great, I managed to introduce a typo... Thanks for spotting it. It's fixed on my side. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
leadin -> leading Otherwise I like it. Cheers, Marta On Sun, Nov 10, 2013 at 6:28 PM, Kevin Ottens wrote: > Hello community, > > After the publication of the initial version of the manifesto, I said I'd > act > as curator for the time being and that it should be a living document which > would get updated from time to time. > > I didn't really live up to it so far as no revision has been done. But > somehow > I found a small chunk of time today and decided to use it to prepare a new > revision. > > As a matter of fact, I got some feedback from people. Some of the items are > rather large (and I'll send separate emails for those), but there was a > collection of nice wording simplifications. > > That's what this email is about, I'd like to apply the attached patch, it's > mostly about small scale changes. I don't see anything which could be > controversial in there. > > Any opinions on this? I'd like to collect feedback before proceeding with a > vote of the e.V. membership and then a push. > > Regards. > -- > Kévin Ottens, http://ervin.ipsquad.net > > KDAB - proud supporter of KDE, http://www.kdab.com > > > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community > ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] Proposal: KDE Manifesto wording revision
Hello community, After the publication of the initial version of the manifesto, I said I'd act as curator for the time being and that it should be a living document which would get updated from time to time. I didn't really live up to it so far as no revision has been done. But somehow I found a small chunk of time today and decided to use it to prepare a new revision. As a matter of fact, I got some feedback from people. Some of the items are rather large (and I'll send separate emails for those), but there was a collection of nice wording simplifications. That's what this email is about, I'd like to apply the attached patch, it's mostly about small scale changes. I don't see anything which could be controversial in there. Any opinions on this? I'd like to collect feedback before proceeding with a vote of the e.V. membership and then a push. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com diff --git a/benefits.markdown b/benefits.markdown index 0cdad69..78ec683 100644 --- a/benefits.markdown +++ b/benefits.markdown @@ -2,19 +2,19 @@ layout: page title: Benefits of a KDE Project --- -Being part of the international KDE community conveys certain benefits and rights. These include: +Being part of the international KDE community conveys certain benefits: -* Stand on the shoulders of giants +* To stand on the shoulders of giants * Make use of KDE infrastructure for project hosting * Benefit from the experience of the KDE sysadmins * Get support from the larger community with development, documentation, translation, testing, bug handling, etc. * Use opportunities to integrate with a large ecosystem of end-user products - * Create cross-pollination of ideas and innovation through interaction with teams sharing common values + * Interact with teams that have common values, leadin to the cross-pollination of ideas and innovations * Enjoy representation and support by KDE e.V. * Participate in Akademy and other KDE events - * Be considered for financial and organizational support - * Know that your trademark can be secured - * Know that your project's license can be defended via the [Fiduciary Licensing Agreement](http://ev.kde.org/rules/fla.php) + * Receive financial and organizational support + * Know that your trademarks can be secured + * Know that your licensing wishes will be protected via the [Fiduciary Licensing Agreement](http://ev.kde.org/rules/fla.php) * Increase your market visibility through the reputation of the KDE community and KDE promotion tools such as: * pushing project announcements to the Dot and employing other KDE promotion channels @@ -24,7 +24,7 @@ Being part of the international KDE community conveys certain benefits and right for communication on web sites and other channels -Principles of a KDE Project +Commitments of a KDE Project Back to the manifesto diff --git a/commitments.markdown b/commitments.markdown index b046224..7824919 100644 --- a/commitments.markdown +++ b/commitments.markdown @@ -1,27 +1,25 @@ --- layout: page -title: Principles of a KDE Project +title: Commitments of a KDE Project --- -The KDE Project designation carries certain principles and requirements: +The KDE Project designation carries with it certain commitments: * Support the [KDE Code of Conduct](http://www.kde.org/code-of-conduct/) * There is no mandatory Contributor License Agreement * Technical requirements * The project stays true to established practices common to similar KDE projects unless special considerations force it to deviate - * Software assets access model -* Direct write access to the software assets is granted only to KDE contributor accounts -* Direct write access to the software assets is granted to all KDE contributor accounts + * All KDE contributor accounts get direct (and universal) write access to the software assets * Projects that choose not to host their web services on KDE infrastructure need to provide administrative access to the KDE sysadmin team; or, if such access cannot be granted, a regular backup of all the code and data used by the web services should be provided to the KDE sysadmins (except if the service is not an integral part of the project's workflow, community interactions and public image) to ensure continued availability * Copyrights, trademarks and patents - * [KDE licensing policy](http://techbase.kde.org/Policies/Licensing_Policy) should be respected - * KDE branding guidelines should be respected - * Trademark continuity – if the authors of the software abandon it or disappear, they agree to transfer the trademark to the next maintainer - * Patent License - If the code is covered by patents registered by the project itself, those patents must be licensed freely + * [KDE licensing policy](http://techbase.kde.org/Policies/Licensing_Policy) must be respected + * KDE branding guidelines are
