[LEDE-DEV] Apology; Communication

Sat Nov 26 04:12:01 PST 2016

Daniel Dickinson schrieb am 26.11.2016 um 04:44:
> On Fri, 25 Nov 2016 21:27:50 +0100
> Hartmut Knaack <knaack.h at gmx.de> wrote:
> 
>> Hi Daniel.
>>
>> Daniel Dickinson schrieb am 25.11.2016 um 01:26:
>>>
>>> To be clear, I think what I mean by lack of communication is that
>>> the community doesn't see:
>>>
>>> 1) The planned technical directions for the project, including
>>> 	a) Currently prioritized issues and plans to resolve them
>>> 	b) Currently prioritized development tasks and the planned
>>> 	technical directions
>>> 	c) How the community can help with a + b
>>>   
>>
>> In the wiki, there is a ToDo-list, which lists quite some tasks
>> where you can feel free to select one that you like most and get
>> started working on. To reduce redundancy, it may be a good idea
> 
> The wiki is relatively new, and I've been having personal and
> email issues so missed the announcement of it going live.  It seemed
> like ToDo wasn't being kept up to date for some time before that.
> 

Well, the archive is just 2 clicks away from each e-mail you
receive on this mailing list. But there it is:
http://lists.infradead.org/pipermail/lede-dev/

>> if whoever starts to work on any of those tasks, will mention it
>> there. If you need input on the planned technical directions,
>> just send a mail to the mailing list, announcing your intention
>> to work on an issue and outline your concept or request input.
> 
> I attempted to do that by doing what I called URFC patches (Untested
> Request for Commment) that showed what I was trying to accomplish and
> asking for input on whether it was worth pursuing, or if there were
> areas that were not even the right idea for how they should be
> implemented, however I got yelled at for that for doing untested
> patches.  It's kind of hard to ask for feedback if you get no input or
> complaints for trying to get feedback before having a fully working and
> tested patch.
> 

Well, people didn't like this attempt, then you should try to
find one, which convinces people right away. Make it as
convenient as possible to review and test for those core
maintainers.
It's fine to ping on your issue after about 2 weeks without
feedback. Just keep in mind, that nobody is just waiting all day
long for patches to arrive.

> I also have the tendency to work on a bunch of stuff in parallel and
> submit it at all at once; that is something I have to work on.
> 
>> The community can help by getting active. I'm not sure how other
>> community members intend on participating, but speaking for
>> myself: if anything is bothering me, I start working on it.
> 
> I can only speak for myself, and I quite frankly don't feel like my
> attempts at contributing are welcome, even aside from the personal
> issues I've had that add a whole new complication; but I had that
> impression even before I had public issues.
> 

I would even say, that your contributions in the past got you
quite a good reputation. You could see that on a later patch,
which suffered from severe style and quality flaws, and blogic
just told you that he knows that you can contribute properly, so
he would not explain it to you as if you were a noob.
What I mainly saw, was you attempting to do "heart surgery", and
people were alarmed. Again, you need to convince people from the
benefits of your changes. One way would be to fork and then let
people test your result. But there is still the risk, that you
won't convince people and waste your time on such task.

>> wiki.lede-project.org/todo
>>
>>> 2) What the core team would like to see the community help with
>>> outside a + b, for things that are wanted or 'nice to have' but not
>>> currently on the roadmap, or far down the roadmap.
>>>   
>>
>> I'm not sure to understand you here, as the mentioned ToDo-list
>> already lists these things and should be extended, according to
>> further needs.
> 
> One thing I'm not clear on what is needed for the 'stabilising trunk' -
> what are known areas that need work, for example?
> 

https://bugs.lede-project.org/

>>
>>> 3) Links to blogs or what have you of core developers to get insight
>>> into who they are and how they think, even if they are not the most
>>> active or wordy blogs.
>>>   
>>
>> I don't see the importance of who certain core members are or how
>> they think. However, if core systems are changed, there should be
> 
> That's not a requirement but it helps put a human face on the core team.
> 
>> way better communication than we have seen in the past (thinking
>> of the change to the block-mount package some years back, which
>> caused a lot of noise in the forum, due to the lack of documen-
>> tation). So, such things could be mentioned on the ToDo-list as
>> work in progress with a reference to another wiki page, which
>> provides some details on the current progress and should evolve
>> into a documentation of the feature.
> 
> One thing I'd be interested in is email integration of forums with a
> user mailing list; I've never been a fan of forums, but that might be
> just because of lousy interfaces in the past.
> 
>>
>>> 4) A sense of core <-> community interaction aside from minimalist
>>> patch interaction for those not on IRC.  (IRC only captures a very
>>> small number of LEDE/OpenWrt users).
>>>   
>>
>> I don't really understand you here. It was outlined, that there
>> should not be that much of a distinction between core and
>> community members. However, when the forum got on the agenda, it
>> became obvious, that core members should interact with those who
>> volunteer to take over certain projects.
> 
> Yeah, one thing (once I'm in a place where it's a good idea) that I
> want to do is participate in the forums, as that seems to be where
> most of the non-developer community hangs out.
> 
>>
>>> 5) Documentation of and pointers to expected code style, some basic
>>> guidelines on what testing is desired for which type of patches (for
>>> those of us on periphery it's easy to forget things), and so on.
>>>   
>>
>> Same as for OpenWrt: usually refer to the Linux kernel coding
>> style. And test as much as possible. Make use of the Tested-by
>> tag on patch submission or mention if you could not test
>> something.
> 
> What I mean is, if it hasn't been added yet (I didn't see such when I
> looked), there should be links to the kernel coding style guidelines and
> helpful vim (and other editor) tools for making sure one is following
> them that I'm sure have been developed over the years.
> 

That would be nice to have. Yet, it didn't seem to have bothered
anyone else, so far. Most likely, there are two groups: those who
already have got the experience and don't need all that, and
those who are unexperienced and already got scared away. But I
agree, that those who want to attract new people, should work on
such kind of documentation.

> Basically what I mean by this is that expectations should be more
> explicitly stated.
> 
>>
>>> There are some exception to that rule in the core team, but for the
>>> most part the core team is a silent mystery.
>>>   
>>
>> You could browse through the git history to see, what certain
>> core members have been working on.
>> Now, try to move your focus away from that core team and think
>> about what you want to contribute (for example your changes to
>> the toolchain). Think about, who and why would benefit from it.
>> Double check your code, may it have a negative impact on others?
>> Put it into chunks, that a reviewer can handle in a short time,
>> and try to convince people from the benefits. Don't try to rush
>> it, take one step after another and wait for the responses.
>> Good luck!
> 
> My biggest problem at the moment is that I'm dealing with issues that
> hinder my contributing well and patiently, which is why I'm taking a
> break from LEDE/OpenWrt.  Sometimes patience is difficult such as when
> patches sit for a month or months and get no indication of thoughts
> (even giving reasons why we he overall idea doesn't fit would be
> helpful in guiding next steps and reactions).  Being ignored is worse
> than getting told 'no, because...' (assuming the because is the actual
> reason) because then at least one has an answer and a something to work
> on or consider.  Not knowing *why* something has gotten no response
> leaves one guessing as to the actual cause.
> 

The simple solution is to ping back on your issue after a
reasonable time. And as said before, smaller chunks are easier
to process. Big chunks are usually postponed.

> And the big dumps tend to be a result of working on multiple things in
> parallel and ending up with things that work at about the same time;
> that is something I know I need to work on.  It's difficult, though,
> when I see even small, individual patches, sitting for long periods of
> time; it would take an extremely long time for anything to happen for
> things that interest non-core developers but not core developers if the
> small, slow approach were taken (by which I mean six months to a year
> for some contributors).
> 
> What's really needed is for the core developers to add some of the
> contributors who have submitted patches well in the past and give them
> access, (actively seeking out new developers not passively waiting for
> requests too), an provide a reasonable level of guidelines into what is
> expected for accepting patches etc., rather than assuming that new core
> will immediate 'just know' what to do, or trying to wait for new
> developers they instantly recognize as talent, to magically show up.
> 

There is no simple solution, as there is a lot of responsibility
involved. So, a proper reputation needs to be earned, first.

> Regards,
> 
> Daniel
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xFAC89148.asc
Type: application/pgp-keys
Size: 3086 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20161126/127aea47/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20161126/127aea47/attachment-0001.sig>