[wp-hackers] Easy-Hacks for WP

john malc dimitrijenko at gmail.com
Wed Feb 1 14:18:34 UTC 2012


After reading this, I decided NOT to do this project. But still, one day, I
would like to have it.

2012/1/31 Stas Sușcov <stas at nerd.ro>

> În data de Tue, 31 Jan 2012 21:23:22 +0200, Jesper Jarlskov <
> jesper at jarlskov.dk> a scris:
>
>
>  I have on several occasions talked to the people behind the Linux
>> distribution Exherbo[0]. They have had great success getting new
>> contributors onto the project by keeping a bunch of low hanging fruits
>> around. This is stuff that is not critical, ie not security issues and so
>> on, but small easy to grasp usually nice-to-have features, that could
>> easily be fixed by the core developers. They make sure to always keep some
>> of these issues around to give aspiring contributors an easy way to get
>> started on contributing.
>>
>> I really like this idea and I know, as mentioned, that other projects has
>> had great success with it. I think one of the biggest problems to getting
>> new contributors on a project is that first commit.
>>
>> [0] http://exherbo.org/
>>
>> Jesper Jarlskov
>>
>>
>> On Tue, Jan 31, 2012 at 8:11 PM, Chris Williams <chris at clwill.com> wrote:
>>
>>  IMHO, the last thing a relatively mature codebase like WP needs is people
>>> randomly tossing in a bunch of "easy hacks".  Every piece of code needs
>>> to
>>> understand the context it is in, needs to respect the coding, data, and
>>> structural paradigms, and needs to play well with the past, present, and
>>> future of the codebase.
>>>
>>> In my experience, some of the most insidious bugs in the projects I have
>>> worked on were introduced by well-meaning people who simply didn't
>>> understand the context well enough.  I would rather have some of these
>>> small, even trivial, bugs lie fallow rather than have them "fixed" in a
>>> way that introduces more bugs, more complexity, or even hamstrings the
>>> codebase against some larger, more elegant, long-term solution that may
>>> be
>>> in the works.
>>>
>>> But that's just my $0.02,
>>> Chris
>>>
>>> On 1/31/12 8:20 AM, "john malc" <dimitrijenko at gmail.com> wrote:
>>>
>>> Can i get more ideas by people on it. Agree/ Not agree etc
>>>
>>>
>>
> Hi,
>
> All this easy-hacks thingy sounds much like a primitive code review
> workflow.
> Nowadays this problems are solved by tools like gerrit/patchwork or
> continuous integration systems.
>
> I understand that everyone wants his patch accepted or reviewed, but the
> problem you described can't be solved like that, simply because more
> patches doesn't mean more code gets accepted. And it's a bit unfair to ask
> a developer to do a job that can be automated (like codestyle check,
> validity of the diff file, quality of the code).
>
> The example with a linux community is also a bit unfair, since a linux
> project is usually split into submodules and sub-projects that have own
> maintainers.
>
> To sum up my thoughts, it's not the workflow that has to be changed, it's
> that WordPress needs more tasks to be automated before a patch review
> request is fired to devs.
> In the end, as scribu said, it should mainly simplify the commit process,
> not replace it.
>
> As a parallel note, there's a thread "Unit Testing" that was started,
> which questions solved, could definitely simplify the commit process.
>
> ______________________________**_________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.**com <wp-hackers at lists.automattic.com>
> http://lists.automattic.com/**mailman/listinfo/wp-hackers<http://lists.automattic.com/mailman/listinfo/wp-hackers>
>



-- 
Malcjohn


More information about the wp-hackers mailing list