srobo / dev-team-proposal Goto Github PK

From #1 (comment):

A separate thought has just occurred to me -- we have quite a lot of repos which have their own issue trackers (and in some cases sort-of incumbent maintainers). We should consider how those would interact with the Dev Team.

Do we expect all bug fixes to go via the Dev Team? Would we allow for a continuation of the current setup with maintainers? I'm not sure that this needs to be completely solved now, though we should definitely aim to recognise those already in these roles and not displace them unnecessarily.

I don't think the proposal currently comments on whether a "project group" is open to more volunteers joining it at a later date. The impression I have come away with after reading it is that they are by default closed. This gives me the feeling that this will end up with a bunch of groups that are distant and hard to get involved with.

It's also somewhat unclear what happens if a volunteer wishes to leave a project group. How do they leave it? How do they get replaced?

We (@srobo/trustees) have concerns about ensuring that the projects worked on by the Dev Team are actually relevant to the needs of the organisation and the Core Team (as they are the ones responsible for running the competition - which the majority of development is for!)

They communicate their ideas to the Dev Team and the Dev Team will decide whether the project is beneficial to the organisation.

Maybe here also state that the Dev Team will work with the Core Team to decide whether the project is beneficial or the org and competition.

Additionally they will aim to fulfill the values of Student Robotics, in particular our goal of reflecting reality by incorporating the latest technology whenever feasible.

I know from the discussion that occurred in the pull-request that resulted in this proposal that the wording of 'latest technology' was potentially going to change. I think that as the wording stands right now that it is at odds with the 'reflecting reality' value. It is very rare in the reality of real-world engineering that one is using the 'latest' technology (of course this depends upon your interpretation of newness). In general, as an engineer, you select the most appropriate tool for the job based on many factors and quite often reliability and proven performance is a big factor. 'Latest technology' can potentially indicate a desire to direct SR to using fragile and unproven technology.

I'm not saying that there isn't a time and place to use something bleeding edge, but there has to be a good reason to do so (and if the reasoning is valid then go ahead!). I think that it would make more sense for this to be worded along the lines of incorporating up-to-date proven technology - which is effectively saying the same thing, but helps to remove ambiguity between what people consider 'latest' to mean.

The proposal states:

Project groups are responsible for maintaining projects that they have.

It also talks about how a project group has a "schedule", which I read as meaning that the project group has a finite lifetime. This seems to conflict with the requirement for a project group to maintain something over the years. Some clarity would be good.

Also note that "maintenance" means different things in the three different contexts that outlined in another issue.

Hey,

Great work on this so far. 😄

The goals of the Dev Team are to ensure the long-term longevity of Student Robotics by organising projects that enhance the experience for SR’s competitors and volunteers in line with its values, and enable SR’s long term growth. Additionally they will aim to fulfill the values of Student Robotics, in particular our goal of reflecting reality by incorporating the latest technology whenever feasible.

I have some questions about this:

• What kind of metrics (either quantitive or qualitative) would the Dev Team measure to evaluate whether they are achieving the above goals?
• These goals provide a far wider remit than building software or hardware, and talk generally about improving the experience and long-term growth. Is this intentional, and if so, do you have any examples?

In the current proposal, 'project groups' propose projects to the dev team. The dev team then accepts or rejects them. This means that a load of volunteer time will have been wasted in developing proposals. Those volunteers will be less enthusiastic to continue contributing. Furthermore, those volunteers will be subject to the sunk-cost fallacy and want to continue developing whatever it was that they proposed, so will end up being alienated further.

The dev team should have a coherent vision that it pursues and communicates to volunteers. (This is related, to the things I have said in #10 and #13).

If there is no coherent vision, then development will be unfocused and move in essentially random directions. This will reduce the impact of the resources (money, volunteer time) that are spent on said development. Engaging volunteers behind a shared and clear vision will also enthuse them and bring further meaning to what they are doing, resulting in happier volunteers who are more likely to invest more time in SR, and are more likely to attract more volunteers to work on SR.

I have already mentioned splitting the dev team into three separate groups in #8 -- kit, competition software, and competition event software. If this is done, then the three groups can each distinctly define their vision of the things that they are responsible for.

Having a direction that the organisation is heading in is one of the key differences that sets SR apart from other FOSS projects, like GNU Emacs for example. Other projects frequently just accumulate contributions from 'drive-by' contributors, and so move in fairly random directions. SR has goals, and it should use the resources that it has to engage development in specific directions.

How do we incorporate non-technical changes? For example, we know we'd like to drop media consent forms, but doing so requires considerable investigation into the legal aspects.

Would this fall under the Dev Team? If so, the current proposal #1 probably isn't a good fit.

The proposal currently states:

A project group is a smaller group of one or more self-selected volunteers who have a particular interest in working on something together.

This is not ideal as it means that basically only volunteers who have the confidence to form a project group will do. Volunteers who want to get involved in development, but do not have the confidence to form a group (or don't know anyone else to form a group) will not. This does not lead to a diverse set of volunteers, but rather filters for volunteers who are basically all the same (i.e. white male, educated at an English university, and also most likely who are all at the same location and age).

Furthermore, getting to the point of proposing a project will require a fair amount of knowledge of the working of SR. New volunteers will have ideas as will those who have been involved for a long time, and the mechanism for getting these ideas into the 'system' should be the same for all. It should be the dev team's responsibility to oversee the collation and formation of project ideas (through more than just a github project of issues -- it should engage volunteers, teams, education experts, robotics experts, and literature in their formation), as well as the formation of the volunteer groups who are going to be involved in it. It should also be responsible for providing a way of presenting the current options that are available to volunteers.

The development process should present an open and welcoming environment people with different kinds of skills, and having 'self-selecting' groups will not encourage this diversity.

The Development Coordination team (a.k.a. the Dev Team) is a group of volunteers that are chosen annually in a similar fashion to the formation of the Core Team, although they may be responsible for projects beyond the annual timescale.

We (@srobo/trustees) were wondering what the reasoning is behind the Dev Team operating in the same annual fashion as the Core Team. There's nothing necessarily wrong with this, we'd just like to understand the reasoning behind this.

Possibly related to #14 and #10, but thinking more about the team itself, I suggest that a part of the aim of the leadership of the Dev Team be to foster a community of volunteers who are interested in collaborating on the Dev Team's vision.

While the current proposal talks about project groups and a little about volunteers, it doesn't really talk much about how to make that sustainable. Fostering a community of volunteers is one way to ensure the sustainability of the overall group.

The current proposal makes no mention of how things like bug reports or existing recorded issues are handled. I'm mostly thinking of small things though I imagine we could end up with some medium-sized projects which have already been specced out and are essentially waiting someone doing them.

For this sort of thing, where a bug report on GitHub could be solved by a quick fix and a PR, the current process feels highly likely to inject unnecessary overheads into what could be quite a simple flow.

This possibly interacts with #3 as the flow I'd hope that the above described things would have is something like:

1. bug report appears, possibly via the forums or otherwise
2. (optionally) brief discussion in slack/wherever happens to find someone interested in fixing it
3. volunteer self-assigns github issue
4. volunteer hacks on stuff
5. volunteer submits PR
6. PR is tested & code reviewed by another volunteer (perhaps the maintainer of the tech area, maybe not)
7. PR is merged
8. deployment happens (ideally automatically where that is viable)