Re: [kde-community] KBibTeX

[Andreas Cord-Landwehr]

Hi Thomas,

if the manifesto [0] works for you, I think we can proceed as Albert 
suggested. For the KBibTeX SVN I already created SVN to Git migration rules 
[1]. The ready to review converted repositories are at:

* 
* 

With your KDE developer account you can then request new playground 
repositories for both at http://sysadmin.kde.org/tickets/ and then proceed the 
path through kde-review to extragear as described at [2]. Please say if you 
need any help on this way!

Greetings,
Andreas

[0] 
[1] 

[2] 
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Discussion: KDE Manifesto, "established practices"

[Aaron J. Seigo]

On Tuesday, November 12, 2013 10:52:45 Peter Grasch wrote:
> 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".

i understand that; however, putting that language in the Maneifesto was a poor 
way of gong about it. there are 3 reasons for this:

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.

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.

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"

> 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.

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.

> 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"?

> 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.

> 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.

our written policies have things like "Honor KDE coding policies” which states 
that this varies and is documented elsewhere. “if in doubt ask on the mailing 
list” is what it says.

http://techbase.kde.org/Policies/Commit_Policy#Honor_KDE_coding_policies

no reasonable person is going to look at “stays true to established practices” 
and think “well, that’s 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.

i agree that it is a valuable aspect of the community. this particular wording 
in this particular document is not the way to communicate that. why? because 
it will be used in ways we do not want in future.

> 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?

which established practices did Necessitas not follow?

-- 
Aaron J. Seigo
___
kde-community mailing list
kde-community@kde.o

Re: [kde-community] Discussion: KDE Manifesto, "web services"

[Aaron J. Seigo]

On Monday, November 11, 2013 20:04:52 Ingo Klöcker wrote:
> Is the "which is approved by the KDE system administration team" really
> needed? 

since they’ll be doing the work and responsible for the outcome (that is the 
mandate we gave them), it is only proper that we agree that the action plans 
we’re going to expect them to support are agreeable to them.

-- 
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

[Valorie Zimmerman]

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

[Eike Hein]

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] Discussion: KDE Manifesto, "established practices"

[Peter Grasch]

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 expla

Re: [kde-community] Discussion: KDE Manifesto, "established practices"

[Aaron J. Seigo]

On Tuesday, November 12, 2013 21:45:40 Peter Grasch wrote:
> On 11/12/2013 06:35 PM, Aaron J. Seigo wrote:
> > 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

there exist people who are not as pedantic as the one you describe who will 
use it in exactly that fashion.

i’d prefer not to trot out dirty laundry from the last 10 years of the KDE 
project to prove my point. please, just trust me on this one: such people do 
exist. it will happen. how do i know? because it has happened.

when it happens, it tends to occur in times of crisis and stress which makes 
it too late to adjust things retroactively with any useful effect. i have sat 
across too many tables from too many frustrated, angry and feeling-like-
they've-been-betrayed people over the years to want to build new ways of 
generating such situations. 

i wanted to see something like the Manifesto specifically because of two 
different projects that pushed boundaries and claimed “special considerations” 
within months of each other (in completely unrelated cases), causing huge 
issues within the community. i ended up spending literally dozens of hours on 
the phone with people and meeting in-person with them to help resolve those 
issues. once completed, i left active participation in KDE e.V. because i had 
had enough of cleaning up messes due to KDE not having the temerity and the 
honesty to set proper boundaries for itself. we fear losing opportunities SO 
MUCH, perhaps because KDE we lack confidence in ourselves, that we create 
situations which actually result in KDE losing opportunities it once had.

this “special considerations” clause is simply classic KDE. and not in a good 
way.

> faceted as a full software development cycle just can't be adressed in
> detail in half a sentence.

the new language doesn’t attempt to do so. nor does it need to. i think we’re 
starting to miss the point here.

the question is do we:

a) put an undefined escape clause in the Manifesto that covers all practices?

or 

b) reference that we have practices defined in the Manifesto that are expected 
to be upheld and leave documenting exceptions to the documentation for each  
specific practice?

the benefits of (b) are:

* we don’t need an exhaustive list of exceptions (or to keep them up to date)
* there is no cart blanche “do whatever” clause available for misuse

to evaluate the utility we should look at this from three use cases:

1) New project coming to KDE seeing if KDE is the place for them.

2) New project understanding what they are committing too and getting in 
return

3) Existing project examining the boundaries of acceptable actions

in *none* of those cases can imagine anyone reading ""The project stays true 
to established practices common to similar KDE projects” and thinking “well, 
aren't they just a bunch of fascists!” 

so the remaining issue is: will new projects evaluating KDE read it to be too 
restrictive? let’s read it in light of the third principle:

"Inclusivity to ensure that people of all origins are welcome to join us and 
participate;”

also note the use of “similar .. projects”. if my project is unique in some 
way .. well ...

so i think it is unlikely to turn projects away in any great number. and i 
expect the most common way this document will get used for projects evaluating 
KDE is by being pointed to it by someone who is associated with KDE, which 
will help with possible questions.

now .. if we have the “special considerations” clause, we will fail for cases 
2 and 3 above.

a new project will enter KDE feeling that they don’t really need to follow 
established practices; they are all just kind of suggestions which you ignore 
when you have a reason to. that does not happen to be how KDE works. by 
leaving in “special considerations” we will be creating false expectations and 
asking people to commit to things under false pretenses.

n the other case, an existing project looking for the boundaries is likely to 
take hold of the “special considerations” clause and use it as justification 
for actions that would otherwise not fit. note that when projects look for 
boundary setting, it is usually when things aren’t going well. clarity and 
truth is paramount at such points in time.

> I could just as easily argue that the new language would have caused
> e.g., the Necessitas p

Re: [kde-community] Proposal: KDE Manifesto wording revision

[Cornelius Schumacher]

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

[Eike Hein]

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

[Aaron J. Seigo]

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

[Aaron J. Seigo]

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

[Eike Hein]

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

[Eike Hein]

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

[Aaron J. Seigo]

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

[Eike Hein]

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] Discussion: KDE Manifesto, "established practices"

[Myriam Schweingruber]

Hi all,

Sorry to top-post, but this is getting wordier and wordier and I have
long lost trace of what is said. Could we have a tl::dr wrap-up,
please?

On Tue, Nov 12, 2013 at 2:54 PM, Aaron J. Seigo  wrote:
> On Tuesday, November 12, 2013 21:45:40 Peter Grasch wrote:
>> On 11/12/2013 06:35 PM, Aaron J. Seigo wrote:


[BIG SNIP]


Thank you in advance, Myriam

-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Proposal: KDE Manifesto wording revision

[Kevin Ottens]

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] Discussion: KDE Manifesto, "established practices"

[Kevin Ottens]

On Tuesday 12 November 2013 18:38:24 Myriam Schweingruber wrote:
> Hi all,
>
> Sorry to top-post, but this is getting wordier and wordier and I have
> long lost trace of what is said. Could we have a tl::dr wrap-up,
> please?
>
> On Tue, Nov 12, 2013 at 2:54 PM, Aaron J. Seigo  wrote:
> > On Tuesday, November 12, 2013 21:45:40 Peter Grasch wrote:
> >> On 11/12/2013 06:35 PM, Aaron J. Seigo wrote:
> [BIG SNIP]
>
>
> Thank you in advance, Myriam

I have to admit I'm loosing track of that particular sub-thread indeed...

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

[Kevin Ottens]

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, "financial support"

[Kevin Ottens]

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

[Kevin Ottens]

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

[Ingo Klöcker]

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] KBibTeX

[Thomas Fischer]

Hello David,

On 11/05/2013 09:36 PM, David Edmundson wrote:
> As a KBibTex user I would happily welcome this.
> 
> I imagine you'll be aiming to be in extragear, so unfortunately you're
> still on your own for release cycles - but there are some utilities
> that will make your life easier.
> 
> Before we continue, can I ask you to go through the KDE manifest and
> check that you agree to all the points listed.
> http://manifesto.kde.org/principles.html

I read the Manifesto and I agree to all its points.

Bye,
Thomas



signature.asc
Description: OpenPGP digital signature
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Proposal: KDE Manifesto wording revision

[Cornelius Schumacher]

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] KBibTeX

[Dominik Haumann]

On Tuesday 12 November 2013 22:15:37 Thomas Fischer wrote:
> Hello David,
> 
> On 11/05/2013 09:36 PM, David Edmundson wrote:
> > As a KBibTex user I would happily welcome this.
> > 
> > I imagine you'll be aiming to be in extragear, so unfortunately you're
> > still on your own for release cycles - but there are some utilities
> > that will make your life easier.
> > 
> > Before we continue, can I ask you to go through the KDE manifest and
> > check that you agree to all the points listed.
> > http://manifesto.kde.org/principles.html
> 
> I read the Manifesto and I agree to all its points.

Cool.

In case you have not already a KDE contributor account, you can request one by 
following http://techbase.kde.org/Contribute/Get_a_Contributor_Account
You'll need a KDE identity, but it's all described there.

Then, you go to https://sysadmin.kde.org/tickets/ and ask the KDE SysAdmins to 
create a new git repository. You'll get instructions how to proceed then and 
how to push all your data.

Welcome to KDE!

If you have any questions, just ask.

Greetings,
Dominik
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] KBibTeX

[Thomas Fischer]

Hello Andreas,

> if the manifesto [0] works for you,
I have agreed to its points, please see my previous mail.

> I think we can proceed as Albert
> suggested. For the KBibTeX SVN I already created SVN to Git migration rules 
> [1]. The ready to review converted repositories are at:
> 
> * 
> * 
Repository kbibtex-www does not need to be migrated to git. It is
used internally at Gna! to create the webpage available at
http://home.gna.org/kbibtex/. It just contains some HTML/CSS/..
files and screenshots. The material will stay available at Gna! even
after KBibTeX's migration to KDE. Before inclusion into any KDE
webpage (techbase, userbase,...) it has to be revised and updated
first, anyway.
Furthermore, some code commits turned up in this git repository. I
am not sure if they are already in the SVN repository, or something
went wrong during the migration ...
Otherwise, the migration script looks ok to me.

> With your KDE developer account you can then request new playground 
> repositories for both at http://sysadmin.kde.org/tickets/ and then proceed 
> the 
> path through kde-review to extragear as described at [2]. Please say if you 
> need any help on this way!
I have already my first question: would be Playground/Edu or
Playground/Office a better fit?

Bye,
Thomas



signature.asc
Description: OpenPGP digital signature
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] KBibTeX

[Laszlo Papp]

On Tue, Nov 12, 2013 at 9:46 PM, Thomas Fischer
wrote:

> I have already my first question: would be Playground/Edu or
> Playground/Office a better fit?
>

office
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Proposal: KDE Manifesto wording revision

[Thomas Zander]

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] KBibTeX

[Thomas Fischer]

Hello Dominik,

> In case you have not already a KDE contributor account, you can request one 
> by 
> following http://techbase.kde.org/Contribute/Get_a_Contributor_Account
> You'll need a KDE identity, but it's all described there.
Check.

> Then, you go to https://sysadmin.kde.org/tickets/ and ask the KDE SysAdmins 
> to 
> create a new git repository. You'll get instructions how to proceed then and 
> how to push all your data.
In progress.

Thanks!

Bye,
Thomas



signature.asc
Description: OpenPGP digital signature
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Proposal: KDE Manifesto wording revision

[Eike Hein]

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

[Thomas Pfeiffer]

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] KBibTeX

[Burkhard Lück]

Am Dienstag, 12. November 2013, 22:57:49 schrieb Thomas Fischer:
> Hello Dominik,
> 
> > In case you have not already a KDE contributor account, you can request
> > one by following
> > http://techbase.kde.org/Contribute/Get_a_Contributor_Account You'll need
> > a KDE identity, but it's all described there.
> 
> Check.
> 
> > Then, you go to https://sysadmin.kde.org/tickets/ and ask the KDE
> > SysAdmins to create a new git repository. You'll get instructions how to
> > proceed then and how to push all your data.
> 
> In progress.
> 
When KBibTeX is pushed into the kde git repos please drop a note to kde-i18n-
d...@kde.org so we can sort out all i18n issues (e. g. moving/renaming existing 
catalogs around) and integrate KBibTeX into KDE's i18n aka Scripty's workflow.

Thanks.

-- 
Burkhard Lück

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community