[Idpy-discuss] Proposal policy to add/remove projects on idpy.org

Hi Ivan, Thanks for this nice writeup. I concur. Heather, can we put a discussion of this onto the agenda for Vienna? What I would add is that this process, or the process we finally agree on, should be documented at http://idpy.org.

Thanks, Scott > Hi everyone, > > The problem we are trying to address is «the process to decide whether > to add or remove a project on idpy.org.» The following is a draft I > put together based on the discussion we had on the call at 09 Jan > 2017. Feel free to change it and enchant it in any way that you think > will make the process smoother. > > > # Project addition > > Accepting the project means accepting the responsibility to maintain > it, and push to fulfil its short and long term goals. How do we make > sure it can do this, and we can help? This is what I'll try to outline > bellow. > > So, a project is proposed to be added: > > > ## Proposal format > > The first thing we need to define is the format of the proposal. > Ideally, I would like to see: > > + Introduction of the maintainer(s): > Introduction could be just a hello from the person in charge. and a > minimal message on that person's availability in relation to the > project development. We do not collect projects, we want the people > that develop those to keep doing that and have them become part of the > organisation and their project part of the ecosystem. > > + Project goals & future: > Project goals are in direct relation to the project's future. Their > relation with idpy.org goals are the first thing to make sure is > aligned. > > + How it relates to idpy.org: > Is there another project that is using the new one as a dependency or > enhancement? Is there a relation to a more generic AAI concept? We > want to know! > > + Current project state: > - How far is the project from its goals? > - What are the problems it is facing (technical / community / dedication-time)? > > + Project metadata: > - URL to project website > - URL to project source code > - URL to project ticketing-system (issue tracker) > - URL to project license > - Communication channels (mailing-list, slack, irc, etc) > > > While all these might seem like too much bureaucracy, each of these > sections could be a couple of lines or even mangled together in a > couple of paragraphs. > > > Once we have such a proposal we should evaluate the project and come > to a conclusion. Bellow are some of the aspects I propose we must take > into account. > > > ## Technical quality > > Is there an architecture document? > How much work is needed to be incorporated with our coding standards > and practices? > Does it have (updated) documentation? > Does it have tests? > Does it have a CI setup? > What other projects does it depend on? > What is going on in the ticketing system (number of bugs and general activity)? > > > ## People quality > > This is a lot harder to judge, but very important. The community is > vital to the organisation's lifecycle. Growing the organisation means > growing the community and accepting more people in its core. While we > cannot prevent people from fighting over (many times even > non-)technical aspects, we can make a priority to make the community > feel safe. Thus we must take notice of how communicative the new > project's maintainers are, what the project's culture is, and whether > this fits to the form of the environment we want to create - an > environment where people are polite and try to understand rather than > dominate. > > This is of course twofold - it is the same thing the other way around. > We are dealing with work done by other people. We must respect that > and be grateful that they put time in this. > > In simpler terms, it is better to not reply to an > issue/question/email, if one is irritated, in hurry or stressed. None > should feel forced to answer or pressured to keep with others' pace. > > > ## Organisation stability > > While a project may fit perfectly, we should always keep in mind what > the organisation's pace is, and how many things it can process at the > same time. Growing should come in a steady fashion to avoid people > getting overwhelmed. Enthusiasm is great and needed but should be kept > in reason with pragmatism. > There is always a right time to do more. We should not be afraid to > reject even good looking matches, as doing so does not mean that there > is no way of even having that chance again. > > The same way we require a project to be in a certain form to be > accepted, the same requirement is on us to be in a state to accept > that project. > > To put it in another way, the organisation should help its project > move forward, and give tools and services to the community. If it is > in a state that is struggling, then accepting a new project does not > help neither party. > > > ## Discussion and consensus > > Everyone should do their homework, go through this list and then > decide whether they think it is a good idea and timing to accept the > project. While a message outlining their basic reasoning is wanted, a > simple +1 or -1 should suffice. > > Keep in mind that a "-1" is *important to express*. It is very common > to only see +1 replies, accept the new thing, and then being into a > situation where many people do not like the new state but never > expressed it. In the long run, this will lead to problems within the > organisation. > > My view on this is that it is many times harder to express rejection > as it seems to place people in a position where they have to explain > themselves. I reject this as a belief, and consider both +1 and -1 > equally important and available with no justification. I cannot > understand how a +1 should be self explanatory, while -1 should not. > So I urge people to freely chose what they think is best for the > organisation at the time of the proposal and do express themselves. > > > ## Process duration > > We should put a limit on the overall process duration and at some > point come to a final conclusion. I do not have a good estimate, I'd > guess 4 weeks should be enough, even for people who may want to have a > say but are away on vacation etc. > > Needless to say, that the community members must trust the decisions > of other members, and as such should not demand that they are present > in every process. As pragmatists (are we?), rough consensus is what we > are striving for - unanimity is pretty hard to achieve. > > > ## Aftermath > > - Set a member responsible for the overall supervision of the project > (the existing maintainer(s) most probably). > - Announce the conclusion to our communication channels > (announce-mailing-list, slack, website, blog, twitter, etc) whatever > the conclusion is. Transparency is important for the community as it > builds trust and portrays a certain level of maturity. > - Incorporate the code: Add project under the github organisation > - Incorporate the people: Add members to the appropriate lists and > other tools (github policies, travis, slack channels etc) > - Open appropriate issues to integrate the new project with existing projects. > - Add to the projects roadmap anything related to the organisation or > things that come up in the proposal discussion. > > > # Project removal > > Removing an existing project should follow the same process. The > difference is that if decided, the actual process needs planning. The > project might be a dependency or part of another project, and as such > it should either be replaced (no functionality lost) or removed in way > that users and services are not affected. > The same way we want a steady removal of that project, the same thing > will be wanted by other people that could be using this. We should > reach out to project we know that they are using that component and > ask them to either adopt it, or replace it. > > A good experiment for this will be the replacement of pyoidc/oic from > satosa (if we decide this) and the integration with the new libs by > Roland and Google. > > > That's all for now. Do tell me what you think and as said before, feel > free to alter and enhance this. > > Cheers, > > -- > Ivan c00kiemon5ter Kanakarakis >:3 > _______________________________________________ > Idpy-discuss mailing list > Idpy-discuss at lists.sunet.se > https://lists.sunet.se/listinfo/idpy-discuss _______________________________________________ Idpy-discuss mailing list Idpy-discuss at lists.sunet.se https://lists.sunet.se/listinfo/idpy-discuss