[LEDE-DEV] Apology; Communication

[Daniel Dickinson]

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.

> 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.

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.

> 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?

> 
> > 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.

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.

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.

Regards,

Daniel