[LEDE-DEV] Apology; Communication

Hartmut Knaack knaack.h at gmx.de
Fri Nov 25 12:27:50 PST 2016


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

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.

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

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

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

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

Hartmut

> 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/20161125/b4559571/attachment.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/20161125/b4559571/attachment.sig>


More information about the Lede-dev mailing list