Re: junior kernel tasks

On Tue, Oct 28, 2014 at 1:35 PM, Marcus von Appen <mva_at_freebsd.org> wrote:

>
> Quoting John Baldwin <jhb_at_freebsd.org>:
>
>  On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote:
>>
>>> Hello,
>>>
>>> In short, nice kernel tasks people with C language skills can do in few
>>> evenings.
>>>
>>> https://wiki.freebsd.org/JuniorJobs
>>>
>>> It is assumed you know how to obtain sources and build the kernel.
>>>
>>> What you can get in return:
>>> - your own code in FreeBSD tree
>>> - eternal glory [1]
>>> - fun [2]
>>>
>>> If you are not interested, but know someone who does, please pass it
>>> down.
>>>
>>> [1] - not really, no
>>> [2] - well, I guess that's subjective, so that's not a "no"
>>>
>>
>> Even though our bugmeisters have decided that we should not have wishlist
>> items in our bug tracker, I really wish we could store the various idea
>> lists
>> (we have several) in an issue tracker instead.  This would allow for
>> folks to
>> comment on ideas, vote for them, etc.  It would also make it easier for
>> more
>> people to submit new ideas.
>>
>>
> Speaking not strictly with the bugmeister hat, but from experience, please
> do
> not let us go down the road of (ab)using a bug tracking solution as task
> and
> idea management system. I think that using the tasks feature of phabricator
> (our reviews instance) would provide better workflow support for those
> things,
> starting out from sketching out rough ideas, discussing them, breaking
> them up
> in seperate tasks (linked to and dependent on each other) and collaborating
> on them (take a look at https://developer.blender.org/T42339 for a brief
> example).
>
> Having said this, let's keep the bug tracker a bug tracker.
>
> Cheers
> Marcus
>
>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>


I do not know difficulty of maintaining a tracker such as "bug tracker" , a
different tracker such as "development tracker" may be defined and used .
In that way , ideas which are not expressible as "bug" in "bug tracker" (
because sometimes it is not possible to decide whether a problem is "bug"
or a "design decision" ) may be specified in " development tracker"  and be
followed from there .

With such a structure the improvement ideas will not be lost in individual
mails .
At some point an idea may be considered useless or inapplicable but over
time it may become very feasible but forgotten or the same person may not
mention it once more .

Thank you very much .

Mehmet Erol Sanliturk