Re: Paths into Debian

2013-10-01 Thread Chuck Peters 
Moray Allan said:
> 
> - Whether/how it would be useful to promote more local Debian groups

I didn't see the Local Groups page mentioned.
https://wiki.debian.org/LocalGroups 

I attended at least one of the group meetings more than 10 years ago, 
but the group is no longer active and I am not longer in the area.


Chuck


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131002034918.gn25...@xen.axs.org

Re: Paths into Debian

2013-09-29 Thread Daniel Pocock 


On 25/09/13 11:51, Thijs Kinkhorst wrote:
> On Tue, September 24, 2013 14:02, Stefano Zacchiroli wrote:
>> On Tue, Sep 24, 2013 at 07:51:53AM -0400, Paul Tagliamonte wrote:
>>> Its not just you - while I appreciate using a word other than bitesized
>>> or
>>> low-hanging-fruit, I tend to get the same slightly off putting feeling
>>> about "gift"
>>>
>>> Not to bikeshead.
>>
>> So, folks, what do you propose instead? :)
>>
>> If the chosen terminology send the "wrong" message, and hence it's
>> potentially a blocker, let's change it (but better do it only *once*,
>> hence the need of getting it "right" this time).
> 
> I would name it after what you want it to signal. If it wants to signal
> starting points for new contributors at entry level, then startingpoint,
> newcontributor or entrylevel could be good choices that leave not much to
> interpretation.
> 

My feeling is that "newcontributor" or "startingpoint" is a message that
is essentially derived from the fact that the bug is somewhat
self-contained or easy to resolve.

A strong solution would probably make some low level classification
(e.g. java+beginner or whatever) and then some portal for new
contributions could be constructed that has links to various reports
that will help them.

E.g. the portal would try to help people rate themselves

a) preferred one or two programming languages,
b) years of experience,
c) career level (student, graduate, professional, hacker)
d) packages (or sections) they are interested in (e.g. science, finance,
networking)

and from there it would prepare a bug search query using some assortment
of tags that will reveal discrete tasks they can complete.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52489493.3010...@pocock.com.au

"Press path" (Re: Paths into Debian)

2013-09-29 Thread Filipus Klutiero 

Hi Daniel,

On 2013-09-22 06:46, Daniel Pocock wrote:

[...]


On 29/08/13 20:39, Filipus Klutiero wrote:


It also briefly mentions the "fundraising path" and the "press path",
which are rarely directly accessible for newcomers. Your talk shows
improvements which could be done to our roads and to our maps:
http://www.debian.org/intro/help
http://www.debian.org/devel/join/
http://www.debian.org/devel/join/newmaint

The "press path" has some risk associated with it

Look at the "Jayme Diaz" video to see an extreme example of the press
cutting someone to pieces.


Each path has some associated risk.

I'm not sure what parallel can be drawn between the video and Debian. Debian 
doesn't have interviewers (officially anyway). If you mean that Debian 
contributors could make mistakes when being interviewed, live interviews are 
rare, usually with the DPL or some veteran contributor, not with the kind of 
people we mean when discussing paths into Debian.


The only way to deal with that is to either have people who know their
topic inside out (e.g. because of long time Debian/free software
involvement) or engaging experienced media handlers.



The risk I do see in the press path is a contributor releasing an incorrect or 
otherwise damaging piece of information. But this is not something really hard 
to deal with. Minimal PR reviewing guidelines were suggested on the 
debian-publicity mailing list a couple of years ago.

--
Filipus Klutiero
http://www.philippecloutier.com


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5248913c.3010...@gmail.com

ITS gift tag and specifying requirements in tickets (Re: Paths into Debian)

2013-09-28 Thread Filipus Klutiero 

Lucas Nussbaum wrote:

On 24/09/13 at 08:37 +0200, Thijs Kinkhorst wrote:
> On Mon, September 23, 2013 14:46, Lucas Nussbaum wrote:
> > Did you tag them 'gift'?
> >https://wiki.debian.org/qa.debian.org/GiftTag
>
> This may just be me, as it's very personal, and no offense intended at
> you, but I really detest the name 'gift' of that tag and that prevents me
> from using it.
>
> Tagging something 'gift' gives me a really condescending association,
> where the Big Maintainer has been so kind to hand out a 'gift' of doing
> work to the little newbie who should be grateful to receive it. Because
> these are the connotations of the word gift to me: that people should feel
> happy to receive it, while actually we should be happy if people do work
> for the project.

Yeah, the 'gift' name was intended the other way around: make a gift to
Debian.


With such a definition, it seems every ticket should be tagged "gift".


> I realize this is absolutely not your intention in naming this tag and
> also that it's highly subjective matter. I'm raising it only because it
> prevents me from using it. If it's just me, than that's that.

We could try to tune documentation into either clarifying the 'gift'
name, or diminishing its importance (by hiding the name where it's
not strictly needed).


Whether or not the "gift" name can make sense in some way, I agree the name 
should be avoided. But I'd suggest to consider solutions other than renaming. The gift 
tag appears to convey 2 or 3 pieces of information:

1. The change required is not too difficult
2. Someone can coach whoever wants to do the change and has volunteered
3. Perhaps, the change is "interesting" (not trivial)

The second objective might be achieved better with a field listing volunteers who are 
interested in mentoring whoever wants to work on a fix. A "Resource persons" 
field with email addresses, maybe.
Points 1 and 3 could be achieved with a field indicating the difficulty of solving the ticket. Specifying a difficulty 
for tickets was discussed in #704874 as data instrumental to ticket prioritization. It should be noted that in #704874, 
"difficulty" is essentially synonym to the time needed to implement a fix. Another definition of difficulty 
would be how much skills one needs to tackle a solution. Clearly, there is correlation between these 2 definitions. But 
they aren't the same. Some changes may require following a simple method, but they can be costly if a lot of code needs 
to be examined. The "small" and "bitesized" suggestions from others make me think about the first 
definition (cost), not about the kind of difficulty which the "gift" tag seems to be interested in.

A rather simple way to specify requirements could be to quantify the time 
needed for solving and to separately say how skilled an interested contributor 
would need to be. #234567 needs 1 hour from a contributor with medium skills, 
say.
Obviously, such a system would be imperfect. Someone with high skills may be 
able to solve in, say, just 40 minutes. Or, someone with low skills could have 
to start by spending an hour learning, but still manage to solve after.
Moreover, quantifying someone's Debian development skills in a simple scale 
going from lowest to highest is quite simplistic. Just see SourceForge's 
developer profiles to see how granular skills can be made.

In addition to the intrinsic difficulty of specifying requirements, we must 
consider that the exact skills needed to solve an issue are sometimes not well 
known in advance, and that time spent specifying required skills is costly.

With all these difficulties, I think it would be wise to try finding 
inspiration in how other ITS-s specify requirements (those I know don't).

I wish a solution could also get rid of the help tag, although we'd first need 
to agree on what that one means. If it means maintainers don't have enough 
time, shouldn't maintainers rather file an RFH (or find some other way to 
attribute that information directly to the package)? If it means a change would 
take too much time for them or require too much skills, then the fields 
discussed above appear to be less relative solutions. If it means a change is 
important, an importance field as discussed in #704874 would be more meaningful.

--
Filipus Klutiero
http://www.philippecloutier.com

Re: Paths into Debian

2013-09-25 Thread Thijs Kinkhorst 
On Tue, September 24, 2013 14:02, Stefano Zacchiroli wrote:
> On Tue, Sep 24, 2013 at 07:51:53AM -0400, Paul Tagliamonte wrote:
>> Its not just you - while I appreciate using a word other than bitesized
>> or
>> low-hanging-fruit, I tend to get the same slightly off putting feeling
>> about "gift"
>>
>> Not to bikeshead.
>
> So, folks, what do you propose instead? :)
>
> If the chosen terminology send the "wrong" message, and hence it's
> potentially a blocker, let's change it (but better do it only *once*,
> hence the need of getting it "right" this time).

I would name it after what you want it to signal. If it wants to signal
starting points for new contributors at entry level, then startingpoint,
newcontributor or entrylevel could be good choices that leave not much to
interpretation.


Thijs


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/26c741fbd780f1975b4e16a36c395f3b.squir...@aphrodite.kinkhorst.nl

Re: Paths into Debian

2013-09-24 Thread Russ Allbery 
I think the original intent of "gift" was that fixing the bug would be a
welcome and happy gift to the maintainer, rather than that the bug was a
gift to the person fixing it from the maintainer.  But I agree that
doesn't come across all that clearly.

Stefano Zacchiroli  writes:

> So, folks, what do you propose instead? :)

> If the chosen terminology send the "wrong" message, and hence it's
> potentially a blocker, let's change it (but better do it only *once*,
> hence the need of getting it "right" this time).

We already have an existing help tag for bugs that the maintainer would
like someone else to fix.  As I understand it, the problem with using help
for this purpose was that the help tag could be put on anything up to and
including major rewrites, and the goal of this tag was to identify things
that could be addressed by people new to the package.

Given that, how about something based on the existing help tag, like
help-small?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y56mkwrx@windlord.stanford.edu

Re: Paths into Debian

2013-09-24 Thread Martin Quinson 
On Tue, Sep 24, 2013 at 04:41:18PM +0200, Lucas Nussbaum wrote:
> On 24/09/13 at 14:46 +0200, Daniel Pocock wrote:
> > 
> > Can we use a word that is neutral and obvious?
> > 
> > Maybe "trivial-to-fix" or something like that?
>
> Wouldn't new contributors feel bad if they can't fix a "trivial-to-fix"
> bug?

We could also assume that we are technoids and call it "entry-point"
as a reference to way dynamic linking works. It seems to me that these
bugs may be easy or may be hard, it depends a lot, but they are like
the best way to get involved...

Bye, Mt.

-- 
If you can't do it in ANSI C, it isn't worth doing.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130924153134.gs3...@alphonse.loria.fr

Re: Paths into Debian

2013-09-24 Thread Victor Nițu 
On 09/24/2013 05:41 PM, Lucas Nussbaum wrote:
> On 24/09/13 at 14:46 +0200, Daniel Pocock wrote:
>> On 24/09/13 14:09, Paul Tagliamonte wrote:
>>>
>>>
>>> On Sep 24, 2013 8:03 AM, "Stefano Zacchiroli" >> > wrote:

 On Tue, Sep 24, 2013 at 07:51:53AM -0400, Paul Tagliamonte wrote:
> Its not just you - while I appreciate using a word other than
>>> bitesized or
> low-hanging-fruit, I tend to get the same slightly off putting feeling
> about "gift"
>
> Not to bikeshead.

 So, folks, what do you propose instead? :)

 If the chosen terminology send the "wrong" message, and hence it's
 potentially a blocker, let's change it (but better do it only *once*,
 hence the need of getting it "right" this time).
>>>
>>> I don't want to give the wrong impression - I'll still use the chosen
>>> tag, but if I'm to play the Umarell, I'd be most likely to use "bitesize"
>>>
>>> Seriously, I don't want to get between work getting done, though.
>>>
>>
>>
>> However people feel about "gift", there is also the jargon factor.  For
>> newcomers, jargon is a barrier and potential time waster
>>
>> Can we use a word that is neutral and obvious?
>>
>> Maybe "trivial-to-fix" or something like that?
> 
> Wouldn't new contributors feel bad if they can't fix a "trivial-to-fix"
> bug?
> 
> I think that if we change the name because 'gift' sends a wrong message,
> it would be better to change to something that doesn't try to convey a
> message, like suitable-for-new-contributors, or new-contributors.
> 

Hi everyone!

I've been following the topic for some time; IMHO the word should be
something real, something that is, *literally*, what it claims to be. It
would be far less confusing this way.

I'd like to propose "entry-level" or any variation of it, or at least
hear a reasonable argument favoring jargon terms. FWIW, I agree with
Daniel on this one.

But hey, any longer discussion on this particular terminology problem
bears a high risk of bikeshedding! Let's be all aware of that.


Cheers,

-- 
. o . Victor Nițu
. . o debian.org.ro
o o o nightsh @OFTC

772B 3AD9 007D A980 330F BDCE 03EF 1B1B F206 F2FC


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5241a6c8.6040...@debian.org.ro

Re: Paths into Debian

2013-09-24 Thread Daniel Pocock 
On 24/09/13 16:41, Lucas Nussbaum wrote:
> On 24/09/13 at 14:46 +0200, Daniel Pocock wrote:
>> On 24/09/13 14:09, Paul Tagliamonte wrote:
>>>
>>> On Sep 24, 2013 8:03 AM, "Stefano Zacchiroli" >> > wrote:
 On Tue, Sep 24, 2013 at 07:51:53AM -0400, Paul Tagliamonte wrote:
> Its not just you - while I appreciate using a word other than
>>> bitesized or
> low-hanging-fruit, I tend to get the same slightly off putting feeling
> about "gift"
>
> Not to bikeshead.
 So, folks, what do you propose instead? :)

 If the chosen terminology send the "wrong" message, and hence it's
 potentially a blocker, let's change it (but better do it only *once*,
 hence the need of getting it "right" this time).
>>> I don't want to give the wrong impression - I'll still use the chosen
>>> tag, but if I'm to play the Umarell, I'd be most likely to use "bitesize"
>>>
>>> Seriously, I don't want to get between work getting done, though.
>>>
>>
>> However people feel about "gift", there is also the jargon factor.  For
>> newcomers, jargon is a barrier and potential time waster
>>
>> Can we use a word that is neutral and obvious?
>>
>> Maybe "trivial-to-fix" or something like that?
> Wouldn't new contributors feel bad if they can't fix a "trivial-to-fix"
> bug?
>
> I think that if we change the name because 'gift' sends a wrong message,
> it would be better to change to something that doesn't try to convey a
> message, like suitable-for-new-contributors, or new-contributors.

It is contextual as well

What is "trivial" for an experienced Java programmer is not trivial to a
Java beginner or somebody who only knows Python and C.

My feeling is that a Java task marked "trivial" or whatever should be
trivial for a Java beginner but it would not need to imply that it is
trivial for somebody who knows Python.

Maybe there could be tags such as "java-bitesize" or "python-quickfix"
or "c-trivial" and in each case, it assumes the person attacking it has
beginner level knowledge of the technology in question





-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5241a857.1030...@pocock.com.au

Re: Paths into Debian

2013-09-24 Thread Lucas Nussbaum 
On 24/09/13 at 14:46 +0200, Daniel Pocock wrote:
> On 24/09/13 14:09, Paul Tagliamonte wrote:
> >
> >
> > On Sep 24, 2013 8:03 AM, "Stefano Zacchiroli"  > > wrote:
> > >
> > > On Tue, Sep 24, 2013 at 07:51:53AM -0400, Paul Tagliamonte wrote:
> > > > Its not just you - while I appreciate using a word other than
> > bitesized or
> > > > low-hanging-fruit, I tend to get the same slightly off putting feeling
> > > > about "gift"
> > > >
> > > > Not to bikeshead.
> > >
> > > So, folks, what do you propose instead? :)
> > >
> > > If the chosen terminology send the "wrong" message, and hence it's
> > > potentially a blocker, let's change it (but better do it only *once*,
> > > hence the need of getting it "right" this time).
> >
> > I don't want to give the wrong impression - I'll still use the chosen
> > tag, but if I'm to play the Umarell, I'd be most likely to use "bitesize"
> >
> > Seriously, I don't want to get between work getting done, though.
> >
> 
> 
> However people feel about "gift", there is also the jargon factor.  For
> newcomers, jargon is a barrier and potential time waster
> 
> Can we use a word that is neutral and obvious?
> 
> Maybe "trivial-to-fix" or something like that?

Wouldn't new contributors feel bad if they can't fix a "trivial-to-fix"
bug?

I think that if we change the name because 'gift' sends a wrong message,
it would be better to change to something that doesn't try to convey a
message, like suitable-for-new-contributors, or new-contributors.

Lucas


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130924144118.gb19...@xanadu.blop.info

Re: Paths into Debian

2013-09-24 Thread Alberto Fuentes 

Btw, i didnt exaclty came up with debian-love myself
https://wiki.gnome.org/GnomeLove

On 24/09/13 14:05, Alberto Fuentes wrote:

debian-love? :P


On 24/09/13 14:02, Stefano Zacchiroli wrote:

On Tue, Sep 24, 2013 at 07:51:53AM -0400, Paul Tagliamonte wrote:

Its not just you - while I appreciate using a word other than
bitesized or
low-hanging-fruit, I tend to get the same slightly off putting feeling
about "gift"

Not to bikeshead.


So, folks, what do you propose instead? :)

If the chosen terminology send the "wrong" message, and hence it's
potentially a blocker, let's change it (but better do it only *once*,
hence the need of getting it "right" this time).

Cheers.







--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52419641.4050...@qindel.com

Re: Paths into Debian

2013-09-24 Thread Daniel Pocock 
On 24/09/13 14:09, Paul Tagliamonte wrote:
>
>
> On Sep 24, 2013 8:03 AM, "Stefano Zacchiroli"  > wrote:
> >
> > On Tue, Sep 24, 2013 at 07:51:53AM -0400, Paul Tagliamonte wrote:
> > > Its not just you - while I appreciate using a word other than
> bitesized or
> > > low-hanging-fruit, I tend to get the same slightly off putting feeling
> > > about "gift"
> > >
> > > Not to bikeshead.
> >
> > So, folks, what do you propose instead? :)
> >
> > If the chosen terminology send the "wrong" message, and hence it's
> > potentially a blocker, let's change it (but better do it only *once*,
> > hence the need of getting it "right" this time).
>
> I don't want to give the wrong impression - I'll still use the chosen
> tag, but if I'm to play the Umarell, I'd be most likely to use "bitesize"
>
> Seriously, I don't want to get between work getting done, though.
>


However people feel about "gift", there is also the jargon factor.  For
newcomers, jargon is a barrier and potential time waster

Can we use a word that is neutral and obvious?

Maybe "trivial-to-fix" or something like that?

Re: Paths into Debian

2013-09-24 Thread Alberto Fuentes 

debian-love? :P


On 24/09/13 14:02, Stefano Zacchiroli wrote:

On Tue, Sep 24, 2013 at 07:51:53AM -0400, Paul Tagliamonte wrote:

Its not just you - while I appreciate using a word other than bitesized or
low-hanging-fruit, I tend to get the same slightly off putting feeling
about "gift"

Not to bikeshead.


So, folks, what do you propose instead? :)

If the chosen terminology send the "wrong" message, and hence it's
potentially a blocker, let's change it (but better do it only *once*,
hence the need of getting it "right" this time).

Cheers.




--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52417ff5.70...@qindel.com

Re: Paths into Debian

2013-09-24 Thread Paul Tagliamonte 
On Sep 24, 2013 8:03 AM, "Stefano Zacchiroli"  wrote:
>
> On Tue, Sep 24, 2013 at 07:51:53AM -0400, Paul Tagliamonte wrote:
> > Its not just you - while I appreciate using a word other than bitesized
or
> > low-hanging-fruit, I tend to get the same slightly off putting feeling
> > about "gift"
> >
> > Not to bikeshead.
>
> So, folks, what do you propose instead? :)
>
> If the chosen terminology send the "wrong" message, and hence it's
> potentially a blocker, let's change it (but better do it only *once*,
> hence the need of getting it "right" this time).

I don't want to give the wrong impression - I'll still use the chosen tag,
but if I'm to play the Umarell, I'd be most likely to use "bitesize"

Seriously, I don't want to get between work getting done, though.

  T

>
> Cheers.
> --
> Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
> Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
> Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
> « the first rule of tautology club is the first rule of tautology club »

Re: Paths into Debian

2013-09-24 Thread Lucas Nussbaum 
On 24/09/13 at 08:37 +0200, Thijs Kinkhorst wrote:
> On Mon, September 23, 2013 14:46, Lucas Nussbaum wrote:
> > Did you tag them 'gift'?
> > https://wiki.debian.org/qa.debian.org/GiftTag
> 
> This may just be me, as it's very personal, and no offense intended at
> you, but I really detest the name 'gift' of that tag and that prevents me
> from using it.
> 
> Tagging something 'gift' gives me a really condescending association,
> where the Big Maintainer has been so kind to hand out a 'gift' of doing
> work to the little newbie who should be grateful to receive it. Because
> these are the connotations of the word gift to me: that people should feel
> happy to receive it, while actually we should be happy if people do work
> for the project.

Yeah, the 'gift' name was intended the other way around: make a gift to
Debian. But I see how it can be misunderstood.

> I realize this is absolutely not your intention in naming this tag and
> also that it's highly subjective matter. I'm raising it only because it
> prevents me from using it. If it's just me, than that's that.

We could try to tune documentation into either clarifying the 'gift'
name, or diminishing its importance (by hiding the name where it's
not strictly needed).

Lucas


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130924115758.ga8...@xanadu.blop.info

Re: Paths into Debian

2013-09-24 Thread Stefano Zacchiroli 
On Tue, Sep 24, 2013 at 07:51:53AM -0400, Paul Tagliamonte wrote:
> Its not just you - while I appreciate using a word other than bitesized or
> low-hanging-fruit, I tend to get the same slightly off putting feeling
> about "gift"
> 
> Not to bikeshead.

So, folks, what do you propose instead? :)

If the chosen terminology send the "wrong" message, and hence it's
potentially a blocker, let's change it (but better do it only *once*,
hence the need of getting it "right" this time).

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Paths into Debian

2013-09-24 Thread Paul Tagliamonte 
On Sep 24, 2013 2:37 AM, "Thijs Kinkhorst"  wrote:
>
> On Mon, September 23, 2013 14:46, Lucas Nussbaum wrote:
> > Did you tag them 'gift'?
> > https://wiki.debian.org/qa.debian.org/GiftTag
>
> This may just be me, as it's very personal, and no offense intended at
> you, but I really detest the name 'gift' of that tag and that prevents me
> from using it.
>
> Tagging something 'gift' gives me a really condescending association,
> where the Big Maintainer has been so kind to hand out a 'gift' of doing
> work to the little newbie who should be grateful to receive it. Because
> these are the connotations of the word gift to me: that people should feel
> happy to receive it, while actually we should be happy if people do work
> for the project.
>
> I realize this is absolutely not your intention in naming this tag and
> also that it's highly subjective matter. I'm raising it only because it
> prevents me from using it. If it's just me, than that's that.

Its not just you - while I appreciate using a word other than bitesized or
low-hanging-fruit, I tend to get the same slightly off putting feeling
about "gift"

Not to bikeshead.

T

>
>
> Cheers,
> Thijs
>
>
> --
> To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org
> Archive:
http://lists.debian.org/491fcd683b50d2f0d8aa866bd90d4655.squir...@aphrodite.kinkhorst.nl
>

Re: Paths into Debian

2013-09-23 Thread Thijs Kinkhorst 
On Mon, September 23, 2013 14:46, Lucas Nussbaum wrote:
> Did you tag them 'gift'?
> https://wiki.debian.org/qa.debian.org/GiftTag

This may just be me, as it's very personal, and no offense intended at
you, but I really detest the name 'gift' of that tag and that prevents me
from using it.

Tagging something 'gift' gives me a really condescending association,
where the Big Maintainer has been so kind to hand out a 'gift' of doing
work to the little newbie who should be grateful to receive it. Because
these are the connotations of the word gift to me: that people should feel
happy to receive it, while actually we should be happy if people do work
for the project.

I realize this is absolutely not your intention in naming this tag and
also that it's highly subjective matter. I'm raising it only because it
prevents me from using it. If it's just me, than that's that.


Cheers,
Thijs


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/491fcd683b50d2f0d8aa866bd90d4655.squir...@aphrodite.kinkhorst.nl

Re: Paths into Debian

2013-09-23 Thread Daniel Pocock 


On 23/09/13 19:31, Jakub Wilk wrote:
> * Lucas Nussbaum , 2013-09-23, 14:46:
>> Alternatively, maybe we should review the current process for one-shot
>> patches. Assuming that someone wants to fix a typo in a package and
>> submit it as a patch, the current simpler process is (TTBOMK):
>>
>> 1. 'debcheckout packagename' (but this fails when the package is not
>> maintained in a VCS. maybe it should fallback to using 'apt-get source'?)
>> 2. Build a source package, so that we can run nmudiff later:
>> 'dpkg-buildpackage -us -uc -S' or 'git-buildpackage -us -uc -S'
>> (depending on the Vcs used.)
> 
> If you don't fancy running untrusted code, point 2 is more like this:
> - Build the VCS checkout of the package using "dpkg-buildpackage -S -nc".
> - Grab last version of the same package from the archive.
> - Run debdiff between the two *.dsc.
> - Start reading the diff.
> - Realize that the diff is flippin' huge.
> - Nuke the VCS checkout; use the version from the archive instead.
> 


There are some other ways about it:

- allow untested patch submission - for things like doc fixes, it would
be nice if the maintainer could easily cherry pick such patches from the
bug tracker next time he does a build, no need to expect every
contributor to make a build for such things

- use of CI (e.g. Jenkins) to try and build each contribution.  People
could then contribute patches (possibly cherry picked from upstream) and
the maintainer could see whether the package builds successfully in
Jenkins and if so, the maintainer just makes one click to accept it.
This would be good for packages that are suitable for CI of course.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5240aee2.8080...@pocock.com.au

Re: Paths into Debian

2013-09-23 Thread Jakub Wilk 

* Lucas Nussbaum , 2013-09-23, 14:46:
Alternatively, maybe we should review the current process for one-shot 
patches. Assuming that someone wants to fix a typo in a package and submit it 
as a patch, the current simpler process is (TTBOMK):


1. 'debcheckout packagename' (but this fails when the package is not 
maintained in a VCS. maybe it should fallback to using 'apt-get source'?)
2. Build a source package, so that we can run nmudiff later: 
'dpkg-buildpackage -us -uc -S' or 'git-buildpackage -us -uc -S' (depending on 
the Vcs used.)


If you don't fancy running untrusted code, point 2 is more like this:
- Build the VCS checkout of the package using "dpkg-buildpackage -S -nc".
- Grab last version of the same package from the archive.
- Run debdiff between the two *.dsc.
- Start reading the diff.
- Realize that the diff is flippin' huge.
- Nuke the VCS checkout; use the version from the archive instead.

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130923173128.ga5...@jwilk.net

Re: Paths into Debian

2013-09-23 Thread Lucas Nussbaum 
Hi,

On 22/09/13 at 12:46 +0200, Daniel Pocock wrote:
> - I've started creating wishlist bugs in my packages, these provide
> useful coding tasks for people, especially students.  They are
> particularly useful for GSoC applicants, because they need to
> demonstrate their coding skills during the selection process.  Even
> maintainers who have no time to interact with GSoC or anything could
> still create such bugs and tag them in some way to provide entry points
> for people to start contributing.

Did you tag them 'gift'?
https://wiki.debian.org/qa.debian.org/GiftTag

Tagging them 'gift' makes them get listed in how-can-i-help.

> - the github fork and "pull request" phenomenon.  It is tremendously
> easy for people to contribute what they want.  There has been some talk
> about getting something like Gerrit into Alioth, that may help us in
> that direction.

Alternatively, maybe we should review the current process for one-shot
patches. Assuming that someone wants to fix a typo in a package and
submit it as a patch, the current simpler process is (TTBOMK):

1. 'debcheckout packagename' (but this fails when the package is not
maintained in a VCS. maybe it should fallback to using 'apt-get
source'?)
2. Build a source package, so that we can run nmudiff later:
   'dpkg-buildpackage -us -uc -S' or 'git-buildpackage -us -uc -S'
   (depending on the Vcs used.)
3. 'cd packagename'
4. make the change (which might involve adding a patch with dpkg-source
   --commit, depending on the source format version used)
5. dch --nmu; enter comment
6. build package (and test, obviously)
7. nmudiff

There are lots of variations depending on whether the package is
maintained in a VCS or not, on the source format version used, etc.

Steps 1 and 2 could clearly be improved:
- debcheckout could automatically build the source package
- debcheckout could use gbp-clone instead of git clone, so that the
  local pristine-tar branch would be set up to track the remote
  pristine-tar branch. (a warning is displayed by git-buildpackage,
  though apparently a correct source tarball is generated, so maybe
  the warning is harmless and should not be displayed?)

Additionally, the fact that one needs to think about the source format
version used in step (4) makes things quite inconvenient (though I don't
see how this could be fixed).

Using nmudiff in step (7) is also a bit cumbersome if someone just wants
to submit a patch.

Lucas


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130923124610.ga12...@xanadu.blop.info

Re: Paths into Debian

2013-09-22 Thread Daniel Pocock 

Just a few of my own comments, mainly from interacting with GSoC
students, although this could be just as applicable to anybody:

- While people joining the NM process or the mentors list are aiming to
have some package added, students don't always come with a clear idea of
some package they want to create or maintain.  Rather, they have an idea
about the topic they want to work with (e.g. security, VoIP).

- I've started creating wishlist bugs in my packages, these provide
useful coding tasks for people, especially students.  They are
particularly useful for GSoC applicants, because they need to
demonstrate their coding skills during the selection process.  Even
maintainers who have no time to interact with GSoC or anything could
still create such bugs and tag them in some way to provide entry points
for people to start contributing.

- Maintainer lists (e.g. pkg-voip-maintainers) are full of automated
notifications and may scare people away.  More effort may be needed to
separate discussion from other automated stuff.

- the github fork and "pull request" phenomenon.  It is tremendously
easy for people to contribute what they want.  There has been some talk
about getting something like Gerrit into Alioth, that may help us in
that direction.

- Having a single VCS (e.g. Git or Mercurial and abolishing SVN, CVS)
would also help reduce complexity of Alioth tool support and lower the
learning curve for first-time contributors.


On 29/08/13 20:39, Filipus Klutiero wrote:

> It also briefly mentions the "fundraising path" and the "press path",
> which are rarely directly accessible for newcomers. Your talk shows
> improvements which could be done to our roads and to our maps:
> http://www.debian.org/intro/help
> http://www.debian.org/devel/join/
> http://www.debian.org/devel/join/newmaint

The "press path" has some risk associated with it

Look at the "Jayme Diaz" video to see an extreme example of the press
cutting someone to pieces.

The only way to deal with that is to either have people who know their
topic inside out (e.g. because of long time Debian/free software
involvement) or engaging experienced media handlers.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/523eca7d.2010...@pocock.com.au

Re: Paths into Debian

2013-08-29 Thread Filipus Klutiero 

Thank you Moray, and thanks to all other participants. Interesting topic, and 
good content. There's no limit to how much could be said on the topic, but I'd 
like to comment and add a bit [edit: or a lot].

I understand the talk's goals as easing the integration of new contributors in 
Debian. Newcomers follow a path which we hope is accessible enough that the 
contributor can get as close as possible from a theoretical unattainable point 
where the contributor knows everything about Debian and can contribute to all 
areas. While each contributor follows a unique path, these unique paths are a 
series of paths through which several contributors go.

Each potential contributor who arrives wondering how he can help is starting 
from a unique position determined by his skills and experiences. Moreover, as 
nobody can aim for complete knowledge of Debian, nobody wants to reach the same 
point. The destination chosen by a certain contributor may depend on the 
contributor's career goals. It also depends on the distance, as contributors 
will prefer to travel towards a destination not too far from their starting 
point.

As a project, we have a huge challenge. We must first keep the roads as smooth 
as possible, which, in a Debian-sized world, is an endless task; there are too 
many roads to pave (and maintain). Second, we must advice travelers the best we 
can on where to go and which paths to use so they can reach their destination.

The talk mentions some paths, none of which is as straight as we could hope:

 * the packaging path
 * the translation path
 * the artwork path

It also briefly mentions the "fundraising path" and the "press path", which are 
rarely directly accessible for newcomers. Your talk shows improvements which could be done to our 
roads and to our maps:
http://www.debian.org/intro/help
http://www.debian.org/devel/join/
http://www.debian.org/devel/join/newmaint

As the issues with maps exemplify, improvements aren't necessarily hard to 
make, but costly. We need not only to keep investing in contributor 
transportation, but to invest wisely.

I hope the above gives a good idea of the presentation's topic.


 The packaging path

You point out that we direct prospects interested in the packaging path to 
orphaned packages. http://www.debian.org/devel/join/ does contain:

Taking over an abandoned package is the best way to start out as a maintainer 
-- not only does it aid Debian in keeping its packages well maintained, but it 
gives you the opportunity to learn from the previous maintainer.


There is some logic in this too. Orphaned package are presumably those in the worst 
state, so those which need love the most (in a sense), as the sentence seems to say. 
However, someone's first package choice should probably be based less on how much the 
package needs work and more on how easy (and rewarding) that choice will be. In a sense, 
the sentence also considers this aspect - indeed, I suppose adopting an orphaned package 
must be easier than packaging something from scratch. So I'm wondering if the sentence 
wouldn't be trying to say something simple with an unfortunate choice of words. Could it 
be that by "abandoned package", it just meant packages in need of some help 
(either O or RFA, perhaps even RFH)? I imagine taking over an RFA-d package should be 
easier than an orphaned package. And responding to an RFH even easier than an RFA.


   Packages not on WNPP

That being said, as I read this page, something even more worrying jumps out. 
Although we don't explicitly forbid it, we don't say anything about working on 
packages not on WNPP. In fact, the sentence

If you are interested in maintaining packages, then you should look at our 
Work-Needing and Prospective Packages  list 
to see which packages need maintainers.

makes it very easy to infer that packages not on WNPP don't need [more] 
maintainers. And yet, we've been complaining for years that new packagers 
always work on pet packages rather than packages which matter. In fact, just a 
few hours before your talk, an X.org maintainer led a BoF where he admitted 
intentionally trying to get contributors involved in X packaging by leaving 
some X driver packages rot for some time. Yet, there is no RFH for X on WNPP!

One may argue the maintainer should have sent an RFH. But really, which package doesn't 
need help? Linux does, X does, Iceweasel does, Icedove does, KDE does. It will soon be a 
decade since I started using Debian, and I can only remember thinking once that a certain 
package was really well maintained (congratulations, Shadow package maintainers!). Oh, 
and the ITS now shows 4 of its tickets tagged "help". All packages need help. 
(I'm not sure I'd say RFH-s are pointless, since some packages do need more help than 
others.)

Unfortunately, I don't have a great alternative text to propose. With WNPP, we 
have something clear to tell contributors to do. If a package is RFA-d and you

Re: DebConf slides (was Re: Paths into Debian)

2013-08-29 Thread Holger Levsen 
Hi,

On Mittwoch, 28. August 2013, Moray Allan wrote:
> On 2013-08-28 13:36, Andreas Tille wrote:
> > Thanks for the pointer.  It seems there is currently no way to submit
> > slides to Penta.  I also uploaded my slides to my talks page and
> > added a
> > link to this in Penta.  Is this something we should report or am I
> > just
> > missing something?
> 
> Submitting slides works fine.  But Penta isn't exporting them
> correctly, there's no content behind the generated links.  Someone needs
> to fix this, yes.

these someones are reachable at ad...@debconf.org


cheers,
Holger



signature.asc
Description: This is a digitally signed message part.

DebConf slides (was Re: Paths into Debian)

2013-08-28 Thread Moray Allan 

On 2013-08-28 13:36, Andreas Tille wrote:

Thanks for the pointer.  It seems there is currently no way to submit
slides to Penta.  I also uploaded my slides to my talks page and 
added a
link to this in Penta.  Is this something we should report or am I 
just

missing something?


Submitting slides works fine.  But Penta isn't exporting them 
correctly, there's no content behind the generated links.  Someone needs 
to fix this, yes.


--
Moray


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/056bcffefa66b18386488f504b587...@www.morayallan.com

Re: Paths into Debian

2013-08-28 Thread Andreas Tille 
Hi Moray,

On Fri, Aug 23, 2013 at 08:59:24PM +0100, Moray Allan wrote:
> At DebConf13 I was interested to hear people's views in the
> discussion session on "Paths into Debian".
> 
> The video of the session is available here:
> 
> http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/high/999_Paths_into_Debian.ogv
> http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/low/999_Paths_into_Debian.ogv
> 
> I have also put up a copy of my introductory slides, though they
> really just contain headings for what I said/for discussion, rather
> than much content:
> 
> http://people.debian.org/~moray/paths-into-debian.pdf

Thanks for the pointer.  It seems there is currently no way to submit
slides to Penta.  I also uploaded my slides to my talks page and added a
link to this in Penta.  Is this something we should report or am I just
missing something?
 
> The two points that seemed to gather most potential volunteers were
> improving the Debian website pages about how to contribute, and
> encouraging more local Debian meetings -- I hope that some of the
> apparent enthusiasm on these points can now be channelled into
> productive action!

+1

Kind regards

   Andreas. 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130828123621.gl31...@an3as.eu

Paths into Debian / local groups

2013-08-25 Thread Christian Körner 
Hi,

As Moray pointed out in a previous post [1] we would like to encourage
more local user groups. This is to provide personal contact to Debian
people. Because during the "Paths into Debian" session one of the
impressions  was it would be easier for people who wants to join if they
had personal contact.

There is already a wiki page [2] but looking into the page history a
good few entries seem to be quite outdated. So I'll contact the
localGroup owner and see if they are still valid.

But if you meet up regularly/irregularly (though regular would be
better), could you let me know (on/off list) and I'll update the wiki or
add the required entry.


Cheers,
Christian


[1] http://lists.debian.org/debian-project/2013/08/msg00053.html
[2] https://wiki.debian.org/LocalGroups


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5219ea86.9070...@ps-xaf.de

Re: Paths into Debian

2013-08-24 Thread Jose Luis Rivas 
On 8/24/13 5:03 AM, Jonas Smedegaard wrote:
> Hi Jose,
> 
> Quoting Jose Luis Rivas (2013-08-24 02:34:28)
>> I think we have missed opportunities to bring more people into
>> Debian like not taking enough attention into support Raspberry
>> Pi. [snip]
> 
> That may seem a constructive point, but please read 
> https://wiki.debian.org/RaspberryPi before continuing.

I got that. And I think you did too. Thousands of hackers are using it
and if Raspbian has been so easy to get into it, why not Debian
directly? We are in need of more contributors, after all. And there
are more chances of getting someone to code something into Debian if
they are using a Raspberry than an x86. We should support them.

> 
>> As well as not adapting easily enough to how other people does
>> stuff. We all love APT, but is not the only way to do stuff. Some
>> communities like the Node.js handles their own packages in a
>> different way [snip]
> 
> Debian includes a slew of "local package managers", for users
> wanting Debian only as core system, with different package
> management on top.
> 
> I suspect your issues with Node.js instead are tied to Node.js and
> NPM not shipped with Wheezy and lacking behind even in
> testing/unstable. Those issues are IMO off topic for this thread.

Indeed, they are and as you suspected.

-- 
Jose Luis Rivas
http://joseluisrivas.net/


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52188423.7040...@gmail.com

Re: Paths into Debian

2013-08-24 Thread Jonas Smedegaard 
Hi Jose,

Quoting Jose Luis Rivas (2013-08-24 02:34:28)
> I think we have missed opportunities to bring more people into Debian 
> like not taking enough attention into support Raspberry Pi. [snip]

That may seem a constructive point, but please read 
https://wiki.debian.org/RaspberryPi before continuing.


> As well as not adapting easily enough to how other people does stuff. 
> We all love APT, but is not the only way to do stuff. Some communities 
> like the Node.js handles their own packages in a different way [snip]

Debian includes a slew of "local package managers", for users wanting 
Debian only as core system, with different package management on top.

I suspect your issues with Node.js instead are tied to Node.js and NPM 
not shipped with Wheezy and lacking behind even in testing/unstable. 
Those issues are IMO off topic for this thread.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Paths into Debian

2013-08-23 Thread Jose Luis Rivas 
On 8/23/13 3:29 PM, Moray Allan wrote:
> At DebConf13 I was interested to hear people's views in the discussion
> session on "Paths into Debian".
> 
> The video of the session is available here:
> 
> http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/high/999_Paths_into_Debian.ogv
> 
> http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/low/999_Paths_into_Debian.ogv
> 
> 
> I have also put up a copy of my introductory slides, though they really
> just contain headings for what I said/for discussion, rather than much
> content:
> 
> http://people.debian.org/~moray/paths-into-debian.pdf
> 
> 
> Some of the topics discussed:
> 
> - How do people come to Debian?
> - Possible routes in, and the support offered to different types of
> contributor
> - What we advertise about routes in, compared to other distributions
> - Other things we could do, including a list of initial tasks for for
> new people
> - Whether/how it would be useful to promote more local Debian groups
> 
> 
> The two points that seemed to gather most potential volunteers were
> improving the Debian website pages about how to contribute, and
> encouraging more local Debian meetings -- I hope that some of the
> apparent enthusiasm on these points can now be channelled into
> productive action!
> 

I think we have missed opportunities to bring more people into Debian
like not taking enough attention into support Raspberry Pi. (Which
created Raspbian, and is not the same as Debian definitely. Now we have
a full rebuild of Debian - just wheezy - while things could have been
done inside the project).

As well as not adapting easily enough to how other people does stuff. We
all love APT, but is not the only way to do stuff. Some communities like
the Node.js handles their own packages in a different way and a little
bit of comprehension about this have moved people to prefer SmartOS
which is really hard to understand at the beggining for their servers
instead of the more common Debian distribution. (Being myself a
developer on Node.js full-time, I'm not even using a single .deb package
for handling my Node.js needs. Using .debs would create conflicts with
most people workflow).

These are just 2 examples which could bring huge amount of people into
Debian and don't depend on local Debian groups but specialized ones.

-- 
Jose Luis Rivas
http://joseluisrivas.net/


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5217ff94.3070...@gmail.com

Re: Paths into Debian

2013-08-23 Thread Moray Allan 

On 2013-08-23 20:59, Moray Allan wrote:

- What we advertise about routes in, compared to other distributions


Not mentioned in the room, but relevant is
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608400

--
Moray


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/6d0cf3485ce0624ab456186bd0606...@www.morayallan.com

Paths into Debian

2013-08-23 Thread Moray Allan 
At DebConf13 I was interested to hear people's views in the discussion 
session on "Paths into Debian".


The video of the session is available here:

http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/high/999_Paths_into_Debian.ogv
http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/low/999_Paths_into_Debian.ogv

I have also put up a copy of my introductory slides, though they really 
just contain headings for what I said/for discussion, rather than much 
content:


http://people.debian.org/~moray/paths-into-debian.pdf


Some of the topics discussed:

- How do people come to Debian?
- Possible routes in, and the support offered to different types of 
contributor

- What we advertise about routes in, compared to other distributions
- Other things we could do, including a list of initial tasks for for 
new people

- Whether/how it would be useful to promote more local Debian groups


The two points that seemed to gather most potential volunteers were 
improving the Debian website pages about how to contribute, and 
encouraging more local Debian meetings -- I hope that some of the 
apparent enthusiasm on these points can now be channelled into 
productive action!


--
Moray


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/9373e93872326154e9149b26a261f...@www.morayallan.com