savannah-hackers-public
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Savannah-hackers-public] Prospective Savannah Hacker Evaluation: Ta


From: Assaf Gordon
Subject: Re: [Savannah-hackers-public] Prospective Savannah Hacker Evaluation: Task 13585 (Stive)
Date: Thu, 3 Sep 2015 14:08:52 -0400

Hello Bruno,

regarding the 'requirements' page:

> I thought so while doing the evaluation, however I couldn't find any
> explicit reference to the requirement in the former page
[...]
> I think it's better to make such
> points explicit right there in the requirements page.
[...]
> I know a copy of a license is a requirement, but it was not clear to
> me from my readings of the requirements page
[...]
> IMHO, all requirements should be explicitly listed in the requirements
> page.

The 'requirement' page is short and concise (you'll notice it's also not part 
of the savannah wiki, and is not intended to be modified often).

The other page ("How To Get Your project approved quickly") is meant to expand 
and elaborate on the requirements, and since it is part of the wiki, we can 
expand and improve it as needed (see here for wiki instructions:  
http://savannah.gnu.org/maintenance/HowToAdminThisWiki/ ).

Long ago, I started building a much longer check-list of optional and required 
items:
 http://lists.gnu.org/archive/html/savannah-hackers-public/2014-08/msg00063.html
If you want to build on that and make an even better list - it would be nice 
(the list agrees with many if the items you've mentioned about recommended 
etiquette).

Sadly, I've noticed that the longer the list is - the less people will bother 
reading it.
Many people who submit new projects don't bother reading any of it.
That's why I stopped focusing on the list, and focused more on an automated 
tool that will flag problematic issues.

Improvements to either (the tool or the list) are always welcomed.

> [...] I listed those suggestions and issues because I think
> it's nice to use such opportunities to provide some feedback and
> educate developers on technical matters, specially when that comes
> with a low cost --- as a natural part of evaluating a package.

That's a good intention, but I've learned that this is likely not our place or 
time to suggest "code quality" improvements.


> Speaking for myself, I'm always very grateful to people who suggest
> things I haven't thought about, haven't known or haven't noticed.
> Should I not do the same as a Savannah hacker?

Personally I agree with you - comments given in good faith (and in a courteous 
manner) are welcomed to me.
I can't say the same for everyone.
Many people just want to get their project hosted - with code that's been 
working for them for a long time - they don't want to hear suggestions.

I've also learned that evaluating projects for compliance can take some amount 
of time as it is - and as I try to be faster about it - I don't want to focus 
on nonessential recommended (e.g. code quality and style).

regards,
  - assaf 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]