[Replicant] Replicant Digest, Vol 169, Issue 8

Paul Kocialkowski contact at paulk.fr
Thu Mar 3 18:13:50 UTC 2016


Le jeudi 03 mars 2016 à 12:47 -0500, David Heath a écrit :
> Ok, your call. Progress certainly comes first but I do think less technical
> perspectives are important to keep projects fresh and innovative. Maybe you
> already have enough of those perspectives for now but I'm sure you're aware
> that these sort of projects are more than just programming, which is why this
> page you were revising exists in the first place.

Sure, but the mailing list's purpose is both to have community discussions and
technical discussions and reviews. Technical reviews are not meant to be
accessible to people only interested in the discussions. Since they are clearly
labeled [PATCH], it's really not hard for people to pick what they're interested
in.

>  I actually caught a few of the typos several messages ago but I didn't want
> to comment on a discussion I wasn't entirely clear on. At the very least, in a
> FOS project, less technical people should be encouraged to contribute in
> matters that do not require technical knowledge. Simple is better. Revising
> this page is probably simple enough that it's not worth the trouble but I
> wanted to share my opinion to guide future collaboration.

Well, we took the decision to use git for the website, with all the things that
come along with it. It means that contributing to the website requires some
technical background not directly related to the content itself.

I see this is a bit regrettable, but it's a very specific situation. Our wiki
has a more user-friendly interface and is more likely to receive external
contributions. The website has mostly been handled by me since it started.
GNUtoo sent out his patches publicly, but he's not an external contributor
either (he's one of the project's founder, and has all the technical knowledge
to contribute to that documentation). So at the end of the day, I don't think
it's really an issue that contributing to the website requires git, since
external contributions are unlikely to happen and are not as encouraged as they
are on the wiki.

>  If other people are able to revise this document for you and you simply
> approve it and upload it, you would have more freedom to address more
> technical matters.

I understand your point, but I think the trade-off goes in favor of using git.

> I admit I figured out how to use Git yet but I am just talking about revising
> the web content via mailing list. Using Git makes sense. Using the mailing
> list also makes sense, I just think it could be a bit more accessible.

Well, truth is, when people send out patches, it's easy to comment on them by
answering directly via email. I agree it's harder for introducing new changes,
though.

> If you don't want feedback from people who don't know how to diff, that's
> fine, it might save a lot of time and confusion, but I am always in favour of
> more clarity.

Feedback is always a good thing, but again, the website has very technical
content and has to be handled very carefully (it is our primary reference
material), so we don't encourage external contributions to it as much.

> Regarding the location of the content, I am still unable to find that location
> (git.replicant.us/replicant/website) in previous messages so it is not obvious
> to me but that would definitely help clarify the conversation if that location
> is the "a/" target of your diff.

That's not how git works, sorry. The patch is not just a random way to present a
change, it is used directly by git, so it has to follow a strict syntax. The
best we can do is mention the repository in the subject line.

>  Again, I probably don't have enough information to discuss this properly but
> I just wanted to give you some insight into how less technical members of your
> community might be discouraged from participation. Practicality is certainly
> more important but it is something to be aware of.

I hear your point, but I'm still in favor of using git for the website.

> I actually do enjoy reading the patch review since it helps me learn but I
> will try to figure out how to selectively stop following discussions. This is
> another situation where a less technical user might just unsubscribe because
> they have other things to do besides spending a couple days learning how email
> clients and mailing lists work, even though they might be able to help develop
> the project in some way at some point.

True, but that's not really up to us. You apparently get digests, which makes it
hard to filter what you get. By receiving each email, people can easily discard
the ones prefixed with [PATCH] (by not looking at them, or for the most advanced
ones, setting up filters).

If it turns out development starts making it very hard to follow community
discussions, we might consider separating the development and discussion lists,
but I don't think this is a primary concern for now, given the traffic.

>  This would be a shame since I assume we all want the project grow big and
> strong. Fortunately, I am willing to put in the effort since I want to learn
> more about these things anyway but busy/lazy people could also help develop
> the project in some ways. Thanks for writing back, hopefully this discussion
> is also beneficial in some way. Think of it as customer insight. :)

Thanks for taking the time to write up about this, and sorry for not really
going in your direction. I do agree with your points, but the trade-off goes in
the direction of using git for the website.

> Le jeudi 03 mars 2016 à 11:37 -0500, David Heath a écrit :
> > Just a suggestion, would it be worth putting this into something like
> pastebin
> > or a document that can be directly edited?
> 
> We're using git and patches to coordinate development, as is very usual with
> free software projects.
> 
> > It seems like referencing lines would be cleaner than putting the entire
> > document in every email.
> 
> That's because each paragraph was on a single line. I'll break them up into
> one
> line per paragraph, that will make patches more understandable and easier to
> manage.
> 
> >  I do think this sort of documentation is very important but honestly, I'm
> not
> > even sure what document you are discussing or what its relevance is to this
> > project. I just woke up yesterday and found a bunch of really long messages
> in
> > my inbox. Not a problem for me since I have time to do a bit of research but
> > some members of the mailing list might be even more confused.
> 
> This is patch review going through the mailing list. If you're not interested
> in
> code review aspects, feel free to just ignore emails prefixed with [PATCH]!
> 
> >  I understand what "hardware freedom state description" is after reading it
> > but where is it located on what site?
> 
> That's very clearly for the website repository: https://git.replicant.us/repli
> ca
> nt/website and it doesn't need to be obvious to the non-technical crowd. In
> cases where it's not obvious, I think adding the name of the repository (e.g.
> [website]) in the message subject would be a good practice.
> 
> Those messages are a public way for me to review external changes coming
> through
> the repositories. People might be interested in commenting on those changes,
> but
> at the end of day, I'm the maintainer who's going to be taking the decision to
> merge them.
> 
> --
> Paul Kocialkowski, Replicant developer
> 
> Replicant is a fully free Android distribution running on several
> devices, a free software mobile operating system putting the emphasis on
> freedom and privacy/security.
> 
> Website: https://www.replicant.us/
> Blog: https://blog.replicant.us/
> Wiki/tracker/forums: https://redmine.replicant.us/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20160303/e04f6411/attachment.asc>


More information about the Replicant mailing list