docs: examples: innersource: Org health and issue prioritization #1287
Comments
|
|
|
|
GSoC project idea: Intuitive documentation practices as a vehicle for modular development
|
graph TD
subgraph system_context[System Context for Ideation]
requirements_management[OWASP common-requirement-enumeration<br>[Software System]]
data_storage[oras.land<br>[Software System]]
source_control[Source Code Management Forgejo<br>[Software System]]
engineer[Software Engineer<br>[Person]]
manager[Project Manager<br>[Person]]
project_idea[Project Idea THREATS.md + CONTRIBUTING.md<br>[Document]]
ci_software[Continuous Integration<br>[Software System]]
cd_software[Continuous Deployment<br>[Software System]]
iaas[Infrastructure as a Service<br>[Software System]]
project_idea -->|Understand requirements| requirements_management
requirements_management --> manager
manager -->|Communicate priority of tasks| engineer
engineer --> source_control
source_control --> ci_software
data_storage -->|Pull dependencies from| ci_software
iaas -->|Provide compute to| ci_software
ci_software -->|Validated version| cd_software
cd_software -->|Store copy| data_storage
cd_software -->|Measure alignment to| project_idea
class manager,engineer,project_idea Person;
class innersource NewSystem;
class ci_software,cd_software,requirements_management,source_control,data_storage,iaas ExistingSystem;
end
class system_context background;
|
|
Map tags in github/gitlab/etc. via clustering models to understand which repos are which types of software. Then map to skills of developers to map workstreams for strategic efforts developers want to be involved in. Diff complexity.
|
|
Idea: model projects as k8s resources vis kcp: https://github.com/kcp-dev |
|
https://cloud.google.com/architecture/devops/devops-process-team-experimentation With regards to forcing a single way of doing things on teams - 'This approach only helps poorly run teams - to some extent. Well-run teams typically play along with the process theatre, but try to keep their old way of working. If they can. If they cannot: their output + motivation drops. [...] "The same way “no one is fired for buying IBM”, it’s true that “no one is fired for introducing Scrum/SAFe”. But better engineers/managers sure do leave because of it: to places where team autonomy is a given. Take away autonomy: you’ll never have a world-class engineering team."' - https://mobile.twitter.com/GergelyOrosz/status/1519948934457831431 How does InnerSource relate to this? InnerSource facilitates discovery of team experimentation success stories and provides BKMs which enable easy leveraging of wins across teams. InnerSource is our methodology for actively seeking out and proliferating team successes. It is also the way we measuring the impact of this methodology itself. |
@dffml.config
class BadgeURLConfig:
tiers: Dict[str, str] = field.config(
"Mapping of state to URLs for .svg badge",
default_factory=lambda: {
True: "https://img.shields.io/badge/Maintainance-Active-green",
False: "https://img.shields.io/badge/Maintainance-Inactive-red",
}
) |
|
Explore definition of This is a very text based lenses into what we want to do, probbaly links to repos, maybe even built of the strategic direction which THREATS.md shows.
The above look closely related to Alice, aka the system context, aka the upstream the overlay and the orchestrator, the past, the present and the future
|
…game plan: references: Link to stream of consciousness aka knowledge graph Also link some related issues with more info. Related: #1287 Related: #1315 (comment)
|
Upstream First Development in Federated Software Forges
IntroductionIn a federated environment where various software forges like Gitea, GitLab, and GitHub interact similarly to social platforms like Threads and Mastodon via ActivityPub, the practice of "upstream first" development can be efficiently managed. This document outlines how these federated forges can form ad-hoc organizations to pursue shared strategic principles and plans while adhering to the upstream first development model using a GitHub pull request style workflow. Key ConceptsFederation of Software ForgesFederation allows independent software forges to communicate and collaborate seamlessly. Each forge retains its autonomy while contributing to a larger ecosystem. This is similar to how social networks federate, enabling users from different platforms to interact. Federation in the context of software development means:
Upstream First DevelopmentThis development practice involves contributing changes, enhancements, or bug fixes to the original project (upstream) before integrating them into downstream projects or forks. It promotes:
Workflow for Upstream First Development1. Identify and Plan the ChangeShared Strategic Principles and PlansFederated forges often form ad-hoc organizations to pursue common goals. These organizations should identify strategic principles and plans guiding their development efforts. These principles might include:
Issue TrackingUse a federated issue tracking system to identify and discuss the change needed. Each forge can contribute to the discussion regardless of where the issue was originally reported. This can be managed through:
2. Develop the ChangeLocal DevelopmentDevelopers work on their local forks or branches of the project. Ensure the changes align with the upstream project's guidelines and standards. Best practices include:
Collaborative EffortUtilize federation capabilities to collaborate with developers across different forges. Tools like federated code review and discussion can be beneficial here. Techniques include:
3. Submit a Pull Request (PR)Upstream RepositoryOnce the change is ready, submit a pull request to the upstream repository. This is done in the forge where the original project is hosted. Key steps include:
Federated PRsFederated forges should support cross-forge pull requests, allowing a pull request from a repository on one forge to be reviewed and merged into a repository on another forge. This involves:
4. Review and CollaborateCode ReviewEngage in a thorough code review process. Federated forges can allow reviewers from different platforms to comment and approve changes. Best practices include:
Continuous IntegrationUtilize CI/CD pipelines that work across federated environments to ensure changes meet quality standards. This involves:
5. Merge and IntegrateUpstream MergeOnce the pull request is approved, it is merged into the upstream project. This ensures the change benefits the entire community. Steps include:
Downstream SynchronizationDownstream projects can then pull the latest changes from the upstream project. This keeps all forks and derivatives up-to-date with the latest improvements. This involves:
6. Communication and DocumentationFederated CommunicationUse federated communication tools to keep all stakeholders informed about the progress and integration of changes. This includes:
Documentation UpdatesEnsure that any changes are well-documented. Documentation should be accessible across all federated forges. This involves:
Benefits of This Workflow
ConclusionBy adopting an upstream first development practice in a federated environment, software forges can collaborate more effectively and ensure that improvements benefit the broader community. This workflow, modeled on the GitHub pull request style, leverages the strengths of federation to create a more cohesive and high-quality software development ecosystem. For more details on federation and how to get involved, visit the Forgejo Project. |
@yashlamba @sakshamarora1 and I talked about this last night in relation to @builtree
As a reminder, we are interested in InnerSource and the OpenSSF identifying security threats work (ietf-scitt/use-cases#14) being done in the open source community because it ties back to our initial mission with open source dependency security / maintainability analysis. This work also helps our project (dffml) as we scale out to understand how we can work more effectively across our plugins and the main package. This work also relates to coming up with ways to help the builtree organization scale and be more effective.
We talked about the existing InnerSource demos and how the goal of InnerSource as is it to enable more frequent changes of higher quality with increased reuse and contribution happening across an organization (such as builtree). We talked about how the one could use the CII best practices badging program as metrics, example.
Metrics can also be used to help projects get visibility so that others are aware of their feature sets when they need to reuse a project or aspects of a project. Feature set collection is also useful for analysis of what project efforts need to be joined/consolidated due to similar feature sets (for example the same set of functions in two python projects
utils.py).Metrics can also be about people, this person is at skill level 0-5 for JavaScript, our model could tell us that investing a mentors time in helping them learn JavaScript would accelerate development across projects faster than that mentor talking another issue. (Increase in overall production output, civilization terminology)
builtree has several projects which have potential cross project collaboration (we talked about dffml and the secret vault for the generic CI/CD work). Identification of feature sets helps determine where more opportunities for cross project collaboration exist. it also helps when contributors want to propose a new project, to identify if a similar project already exists. This ties into the inventory.
We talked about how investing in driving up metrics now (before GSoC season) will pay off big in terms of less manual review needing to be done and making contributors more autonomous and enabled to do great work (quality docs, tests, etc.).
We should consider creating some kind of org level health metrics. So that we can see the reuse and contribution happening from maintainers and contributors across projects (cross pollination, metric which describes health of set of projects, potentially the set of projects is the whole org).
We also talked about implementing InnerSource for an open source org could help senior folks in an org prioritize what they should work on when they have a role to help all the projects across the org when needed. Having this traceability and data on potential impact of work (this ties in with the estimating time to complete issue stuff from #1279) allows org admins / maintainers to make data driven decisions about what to work on. They will have a model to see that closing issue X increases throughput or quality, or both across all projects in the org by Y amount (time to close other issues shrinks) as estimated by the model / data flow.
The presentation we did at bsides pdx 2019 shows how we developed methodology for an event driven CI/CD pipeline which yielded insights into open source project maintenance and security posture. The work in this issue is a potential avenue to another presentation. One where we show how we continued work on our CI/CD + ML project to gather further insights on open source projects, including our own. Then though application on InnerSource principles within our orgs, we use those insights to build more effective organizations.
The text was updated successfully, but these errors were encountered: