Contributing to Sugar
Last week I spent some time reading through the wiki, the development team pages in particular. I was curious to see what it was like from the outside, since I’ve not been involved with the project for more than one year.
I have to admit the experience was bad:
* We are missing a technical roadmap. We have a schedule for the next release but it’s not clear what are the goals or even what people are working on.
* We don’t have clear instructions on how to setup a development or testing environment.
* We have no official documentation about activity development. A proper python SDK would go a long way to facilitate activity contributions, in my opinion.
* Some of our processes are a intimidating. I’m thinking about patch submission and new features in particular. It might be more a problem with the wording then with the actual processes.
A couple of more general observations:
* Most of the content looks outdated or the templates are just empty, which gives the wrong impression about the liveliness of the project.
* Reading mailing lists and following irc very regularly seems to be essential to contribute. Unfortunately that requires too much time for most people. I understand it a lot better now that I have an unrelated full time job.
* We have too many teams compared to the active contributors. Maybe merging or dropping some of them would help consolidating resources? For example I’m not convinced core and activity teams should be separated.
I could go on, but these are probably the most important points I wanted to raise. I would like to help addressing these issues, I don’t have a lot of time to spend on it but perhaps that actually gives me a good perspective!
Agreed, there’s lots of non-coding work to do and several people are employed to hack on Sugar. How could we explain the need for this kind of work? I’ve tried to explain it to some of their bosses, but I don’t think I managed to pass the message successfully.
In my experience, this kind of work which is not immediately useful to employers, is usually carried over by the developers themselves, because they care about the project and they see it’s necessary for it to grow as a whole. It’s the same in a closed source environment, you can’t expect your manager to schedule times for refactoring, you have to figure how to do it as part of tasks which are more directly relevant to him. Something we can do to favour this process is probably to involve these developers as much as possible in the maintenance work. You and Simon seems to be still carrying most of the responsibilities, and that’s something which needs to change.
Just a thought, it’s certainly a difficult issue!
Also, I frame this broad issue inside the broader one “thinking about resources”. As a community, we are capable of expressing needs but we don’t seem to discuss publicly at all how we are going to resource all we want to happen.
I agree. I might order the priorities as:
short-term roadmap,
python SDK,
dev environment screencast,
monthly dev-summary (similar to the sugar digest, for devs),
long-term roadmap (for inspiration!),
consolidation of sparse teams and wikipages,
clearer processes
SJ
I like the idea of the monthly dev summary a lot. It’s probably something I could give a try to!
Hi,
I came across your post while browsing Planet Sugar. I thought I’d pop by to say that I agree, from the perspective of a wannabe-contributor to the project. In general I think it’s harder for newcomers to express where processes are going wrong for them or where things are confusing because they don’t feel they have the “clout” in the community to say “I’m sorry, this really isn’t working for me”… Or this is how I’ve been feeling, particularly since SL started requiring every patch to be submitted to the mailing list and only to the list. I do try to follow at least roughly what’s going on on sugar-devel, but I suspect asking to join the list to submit a patch is asking for quite a commitment, for many people.
I’d be happy to help “testing” any developer documentation update you make, and should you take a stab at the monthly dev summary I would be a very happy reader too, it sounds like a great idea!
Hi!
You are making a very good point about newcomers reclutance to express negative feedback. I noticed it a lot and I think it’s one of the main reason things didn’t improve much. I’m not sure how to help it, ideas welcome, but I suspect being more proactive about seeking this kind of feedback would be a start.
About the specific issue of patch reviews. I think the official process is still to open a bug in trac and attach the patch to it. There has been a lot of discussion about using mailing list instead but it was never really decided. The fact that this is not clear is of of course a major problem already
Tackling review process is actually one of my top priorities, so your feedback is very useful. I agree with you, it should be possible to contribute to Sugar without being forced to follow high volume communication channels.
Your comment made me happy, thanks for posting it. Keep feedback coming, your perspective is very valuable!
Thanks! I very much look forward to following your efforts at clarifying the review process, and will think about the other questions you bring up too. Have a great day!