Code Recommendation for Open Source Software Developers

Open Source Software (OSS) is forming the spines of technology infrastructures, attracting millions of talents to contribute. Notably, it is challenging and critical to consider both the developers’ interests and the semantic features of the project code to recommend appropriate development tasks to OSS developers. In this paper, we formulate the novel problem of code recommendation, whose purpose is to predict the future contribution behaviors of developers given their interaction history, the semantic features of source code, and the hierarchical file structures of projects. We introduce CODER, a novel graph-based CODE Recommendation framework for open source software developers, which accounts for the complex interactions among multiple parties within the system. CODER jointly models microscopic user-code interactions and macroscopic user-project interactions via a heterogeneous graph and further bridges the two levels of information through aggregation on file-structure graphs that reflect the project hierarchy. Moreover, to overcome the lack of reliable benchmarks, we construct three large-scale datasets to facilitate future research in this direction. Extensive experiments show that our CODER framework achieves superior performance under various experimental settings, including intra-project, cross-project, and cold-start recommendation.


INTRODUCTION
Open Source Software (OSS) is becoming increasingly popular in software engineering [23,50].As contribution to OSS projects is highly democratized [70], these projects attract millions of developers with diverse expertise and efficiently crowd-source the project development to a larger community of developers beyond the project's major personnel [23,35].For instance, GitHub, one of the most successful platforms for developing and hosting OSS projects, has over 83 million users and 200 million repositories [13].
Community support and teamwork are major driving forces behind open source projects [35].OSS projects are usually developed in a collaborative manner [2], whereas collaboration in OSS is especially challenging.OSS projects are of large scales and usually contain numerous project files written in diverse programming languages [4].According to statistics, the most popular 500 GitHub projects contain an average of 2,582 project files, 573 directories, and 360 contributors.Meanwhile, there are more than 300 programming languages on GitHub, 67 of which are actively being used [11,12].For project maintainers, it is both difficult and time-consuming to find competent contributors within a potentially large candidate pool.For OSS developers, recommending personalized development tasks according to their project experience and expertise can significantly boost their motivation and reduce their cognitive loads of manually checking the project files.As contribution in OSS is voluntary, developers that fail to find meaningful tasks are likely to quit the project development [48].Therefore, an efficient system for automatically matching source code with potential contributors is being called for by both the project core team and the potential contributors to reduce their burden.
To solve the above issues, in this paper, we for the first time introduce the novel problem of code recommendation for OSS developers.As shown in Fig. 2, this task recommends code in the form of project files to potentially suitable contributors.It is noteworthy that code recommendation has several unique challenges such that traditional recommender models are not directly applicable.
Firstly, OSS projects contain multimodal interactions among users, projects, and code files.For example, OSS development contains user-code interactions, such as commits that depict microscopic behaviors of users, and user-project interactions, such as forks and stars that exhibit users' macroscopic preferences and interests on projects.Also, the contribution relationships are often extremely sparse, due to the significant efforts required to make a single contribution to OSS projects.Therefore, directly modeling the contribution behavior as in traditional collaborative filtering approaches will inevitably lead to inaccurate user/item representations and suboptimal performances.
Secondly, in the software engineering domain, code files in a project are often organized in a hierarchical structure [69].Fig. 1 shows an example of the famous huggingface/transformers repository [56].The src directory usually contains the major source code for a project.The data and models subdirectories usually include functions for data generation and model implementations, respectively.Such a structural organization of the OSS project reveals semantic relations among code snippets, which are helpful for developers to transfer existing code from other projects to their development.Traditional methods usually ignore such item-wise hierarchical relationships and, as a result, are incapable of connecting rich semantic features in code files with their project-level structures, which is required for accurate code recommendation.
Thirdly, most existing benchmarks involving recommendation for softwares only consider limited user-item behaviors [5,21], are of small scales [39,40], or contain only certain languages such as Python [20,37,51] or Java [5,21,40], which renders the evaluation of different recommendation models difficult or not realistic.
To overcome the above challenges, we propose CODER, a CODE Recommendation framework for open source software developers that matches project files with potential contributors.As shown in Fig. 2, CODER treats users, code files, and projects as nodes and jointly models the microscopic user-code interactions and macroscopic user-project interactions in a heterogeneous graph.Furthermore, CODER bridges these two levels of information through message aggregation on the file structure graphs that reflect the hierarchical relationships among graph nodes.Additionally, since there is a lack of benchmark datasets for the code recommendation task, we build three large-scale datasets from open software development websites.These datasets cover diverse subtopics in computer science and contain up to 2 million fine-grained user-file interactions.Overall, our contributions are summarized as follows: • We for the first time introduce the problem of code recommendation, whose purpose is to recommend appropriate development tasks to developers, given the interaction history of developers, the semantic features of source code, and hierarchical structures of projects.
• We propose CODER, an end-to-end framework that jointly models structural and semantic features of source code as well as multiple types of user behaviors for improving the matching task.
• We construct three large-scale multi-modal datasets for code recommendation that cover different topics in computer science to facilitate research on code recommendation.
• We conduct extensive experiments on massive datasets to demonstrate the effectiveness of the proposed CODER framework and its design choices.

PRELIMINARIES 2.1 GitHub
GitHub is a code hosting platform for version control and collaboration based on git.Users can create repositories, namely, digital directories, to store source code for their projects.Users can make changes to the source code in the form of commits, which are snapshots of an OSS project, that capture the project state.A GitHub commit mainly reflects two aspects: 1) The commit author is highly interested in the project; 2) the user has the expertise to contribute.In this work, we study the factors that influence users' contributing behaviors.We use git commits as positive interactions.

Problem Formulation
Before delving into our proposed CODER framework, we first formalize our code recommendation task.We use the terms "repository" and "project" interchangeably to refer to an open source project.We define U, V, R as the set of users, files, and repositories, respectively.Each repository   ∈ R contains a subset of files V  ⊊ V.Both macroscopic project-level interactions and microscopic file-level interactions are present in OSS development.
File-level behaviors.We define Y ∈ {0, 1} |U |×|V | as the interaction matrix between U and V for the file-level contribution behavior, where each entry is denoted by    .   = 1 indicates that   has contributed to   , and    = 0, otherwise.
Project-level behaviors.Interactions at the project level are more diverse.For example, the popular code hosting platform GitHub allows users to star (publicly bookmark) interesting repositories and watch (subscribe to) repositories for updates.We thus define T as the set of user-project behaviors.Similar to Y, we define S  ∈ {0, 1} |U |×| R | as the project-level interaction matrix for behavior of type .Our goal is to predict the future file-level contribution behaviors of users based on their previous interactions.Formally, given the training data Y tr , we try to predict the interactions in the test set    ∈ Y ts = Y\Y tr .

METHODOLOGY
As shown in Fig. 2, we design CODER, a two-stage graph-based recommendation framework.CODER considers   ∈ U,   ∈ V,   ∈ R as graph nodes, and models the user-item interactions and the item-item relations as edges.We use two sets of graphs to characterize the heterogeneous information in code recommendation.One is the user-item interaction graphs that encompass the collaborative signals.The other is the file-structure graphs that reveal file-file and User-project interaction graphs < l a t e x i t s h a 1 _ b a s e 6 4 = " 1 r + 2 < l a t e x i t s h a 1 _ b a s e 6 4 = " e c k h 4 W T / X t z V 0 t c l n s 0 h j             file-project relationships from the project hierarchy perspective.
The code recommendation problem is then formulated as a user-file link prediction task.
CODER contains two major components: 1) Node Semantics Modeling, which learns the fine-grained representations of project files by fusing code semantics with their historical contributors, and then aggregate project hierarchical information on the file structure graph to learn the file and repository representation; 2) Multi-behavioral Modeling, which jointly models the microscopic user-file interactions and macroscopic user-project interactions.Finally, CODER fuses the representations from multiple behaviors for prediction.This way, node semantics modeling bridges the coarse-grained and fine-grained interaction signals on the item side.Therefore, CODER efficiently characterizes intra-project and inter-project differences, eventually uncovering latent user and item features that explain the interactions Y.

Node Semantics Modeling
Node semantics modeling aims to learn file and repository representation.The challenge is how to inherently combine the semantic features of each project file with its interacted users and the project hierarchy.To address this challenge, we first use a codeuser modality fusion mechanism (Fig. 2a) to fuse the file content modality and the historical users at the code level.Then, we embed the fine-grained collaborative signals from user-file interactions into the file representations.Next, we employ structural-level aggregation (Fig. 2b), which explicitly models the project structures as hierarchical graphs to enrich the file/repository representation with structural information.This step produces representation for each file   and repository   , which serve as the input for user behavior modeling in Sec.3.2.

Code-User Modality Fusion.
A project file is characterized by diverse semantic features including multiple method declarations and invocations, which are useful for explaining why a contributor is interested in it.Inspired by the success of pretrained language models [24,26,31], we use pretrained CodeBERT [7], a bimodal language model for programming languages, to encode the rich semantic features of each file.CodeBERT is shown to generalize well to programming languages not seen in the pretraining stage, making it suitable for our setting where project files are written in diverse programming languages.Here, a straightforward way is to directly encode each file into a per-file latent representation.Such an encoding scheme has two issues.Firstly, a file may contain multiple classes and function declarations that are semantically distinct.Fig. 1 shows the file structure of the huggingface/transformers [56] repository as an example.The modeling_bert.py file contains not only various implementations of the BERT language model for different NLP tasks, but also utilities for parameter loading and word embeddings.These implementations are distributed among several code segments in the same project file, and file-level encoding can fail to encode such semantic correlations.Secondly, the property of a project file is influenced by the historical contributors' features.A user's contribution can be viewed as injecting her/his own attributes, including programming style and domain knowledge, into the interacted file.Such contribution behaviors make it more likely to be interacted again by users with similar levels of expertise than random contributors.
Therefore, we propose a code-user modality fusion strategy to embed both code semantics and user characteristics into the file representation.Specifically, for each file, we partition its source code into   code segments and encode each of them into a codesegment-level representation c  .This produces a feature map where  is the embedding size.Similarly, we sample   historical users of the file and encode them into a feature map Please refer to Appendix B for details in encoding C and Q. Inspired by the success of co-attention [32,71], we transform the user attention space to code attention space by calculating a code-user affinity matrix L ∈ R  C × Q : where W O ∈ R × is a trainable weight matrix.Next, we compute the attention weight a ∈ R  C of the code segments to select salient features from C. We treat the affinity matrix as a feature and learn an attention map H with  H representations: where Finally, the file attention representation h is calculated as the weighted sum of the code feature map: The file attention representation serves as a start point to further aggregate file structural features.
3.1.2Structural-Level Aggregation.Projects are organized in a hierarchical way such that nodes located closer on the file structure graph are more closely related in terms of semantics and functionality.For example, in Fig. 1, both files under the bert/ directory contain source code for the BERT [26] language model, and files under roberta/ contains implementation for the RoBERTa [31] model.The file modeling_bert.py is therefore more closely related to tokenization_bert.py in functionality than to tokenization_ roberta.py.
To exploit such structural clues, we model each repository as a hierarchical heterogeneous graph [69]  S consisting of file, directory, and repository nodes.Each node is connected to its parent node through an edge, and nodes at the first level are directly connected to the virtual root node representing the project.To encode the features of directory nodes, we partition the directory names into meaningful words according to underscores and letter capitalization, then encoded the nodes by their TF-IDF features.Our encoding scheme is motivated by the insight that the use of standard directory names (e.g., doc, test, and models) is correlated with project popularity among certain groups of developers [2,79].Repository features are encoded by their project owners, creation timestamps, and their top-5 programming languages.The repository and directory representations are mapped to the same latent space as the file nodes.Then, we pass the representation h through multiple GNN layers to aggregate the feature of each node from its neighbors on  S : where h is the structure-enhanced node representation.The aggregation function  GNN (•) can be chosen from a wide range of GNN architectures, such as GCN [28], GraphSAGE [16], and GIN [61].In practice, we employ a 3-layer Graph Attention Network (GAT) [49].

Multi-behavioral Modeling
Direct modeling of the sparse contribution behavior potentially leads to inaccurate user/item representations and aggravates the cold-start issue.Instead, we jointly model the microscopic user-file contribution in File-level Aggregation (Fig. 2c) and macroscopic user-project interactions in Project-level Aggregation (Fig. 2d) to learn user preferences and address the sparsity issue.Then, the representations learned from multi-level behaviors are combined to form the user and item representations for prediction.

File-level Aggregation.
We model the project files and their contributors as an undirected user-file bipartite graph G F consisting of users   ∈ U, files   ∈ V and their interactions.The initial embedding matrix of users/items is denoted by E (0) : is the initial embedding for user   and v is the initial embedding for file   , equivalent to its structure-enhanced representation h (Sec.3.1.2).We adopt the simple weight sum aggregator in LightGCN [18] in the propagation rule: where u () and v are the embeddings for user   and file   at layer , N  and N  indicate the neighbors of user   and file   , and 1/ √︁ |N  ||N  | is the symmetric normalization term set to the graph Laplacian norm to avoid the increase of GCN embedding sizes [18,28].In the matrix form, the propagation rule of file-level aggregation can be expressed as: where is the affinity matrix, and D is the diagonal degree matrix in which each entry D  indicates the number of non-zero entries on the -th row of A. By stacking multiple layers, each user/item node aggregates information from its higher-order neighbors.Propagation through  layers yields a set of representations {E () }  =0 .Each E () emphasizes the messages from its -hop neighbors.We apply mean-pooling over all E () to derive the user and file representations u ★  and v ★  from different levels of user/item features: 3.2.2Project-Level Aggregation.OSS development is characterized by both microscopic contribution behaviors and multiple types of macroscopic project-level behaviors.For example, developers usually find relevant projects and reuse their functions and explore ideas of possible features [20,22].In particular, GitHub users can star (bookmark) interesting repositories and discover projects under similar topics.This way, developers can adapt code implementation of these interesting projects into their own development later.Hence, project-level macroscopic interactions are conducive for extracting users' broad interests.as the training data.We retain the users with at least 1 interaction in both train and test set.More details about dataset construction are in the appendix.
4.1.2Implementation Details.We implemented our CODER model in PyTorch [42] and PyG [8].For all models, we set the embedding size to 32 and perform Xavier initialization [14] on the model parameters.We use Adam optimizer [27] with a batch size of 1024.For Node Semantic Modeling (Sec.For the structure contrastive loss [30], we adopt the hyper-parameter setting from the original implementation and set  2 = 10 −6 ,  = 2 without further tuning.For the baseline models, the hyper-parameters are set to the optimal settings as reported in their original papers.For all models, we search the learning rate in {10 −4 , 3 × 10 −4 , 10 −3 , 3 × 10 −3 , 10 −2 }.
As the task is to predict users' file-level contribution, file-level behavior modeling is the most critical component.Therefore, we use file-level contribution behaviors as the supervision signals as in Eq. (18).For brevity, we use repository identity to refer to the information of which repository a file belongs to.As the baselines do not explicitly leverage the repository identities of files, we encode their repository identities as a categorical feature through one-hot encoding during embedding construction.To ensure fairness of comparison, we incorporate the project-level interaction signals into the user representations by applying multi-hot encoding on the repositories each user has interacted with.All the baseline models use the same pretrained CodeBERT embeddings as CODER to leverage the rich semantic features in the source code.
4.1.4Evaluation Metrics.Following previous works [18,19,53,78], we choose Mean Reciprocal Rank (MRR@), Normalized Discounted Cumulative Gain (NDCG@), Recall@ (Rec@), and Hit@ as the evaluation metrics.This setting corresponds to the scenario in which project maintainers recommend new development tasks to existing contributors based on their previous contribution.As shown in Tab. 2, CODER consistently outperforms the baselines by a large margin.On the ML dataset, CODER outperforms the best baseline by 17.9% on NDCG@20, 15.8% on Hit@20, and 8.2% on MRR@20.On the DB dataset, CODER achieves performance improvements of 27.3% on NDCG@20, 29.5% on Hit@20, and 6.0% on MRR@20.Notably, the greatest performance improvement is achieved on the FS dataset, which has the greatest sparsity.CODER achieves a maximum performance improvement of 37.1% on NDCG@5 and 35.6% on NDCG@10.
The results show that CODER achieves significant performance improvement over the baseline, and is especially useful when the observed interactions are scarce.Among the baselines, graph-based method (G3) achieves better performances than (G1), (G2) as they can model the high-order relations between users and items through the interaction graph and the embedding function.LightGCN [18] underperforms NGCF [53] on the DB dataset, whose training set has the greatest density, and outperforms NGCF on the ML and FS datasets.This implies that the message passing scheme of NGCF, which involves multiple linear transformation and non-linear activation, is more effective for denser interactions.Such results justify our design choice in multi-behavioral modeling, which uses the LightGCN propagation scheme.NCL exhibits the strongest performance, demonstrating the importance of the contrastive learning loss in modeling differences among homogeneous types of nodes, which is also included in our model design.Neural-network-based methods (G2) generally outperform matrix factorization (G1), as they leverage multiple feature transformations to learn the rich semantics in the file embeddings and the user-file interactions.the users' preferences with few observed interactions.Our model is thus designed according to this principle.We define cold-start users as users with ≤ 2 interactions in the training set.To evaluate the model performance with fewer interactions, we choose NDCG@, Recall@, and Hit@, where  ∈ {3, 5}.The strongest 4 baselines in Tab. 2 are evaluated for comparison.
As observed from Tab. 3, performance for cold-start users is worse than that for all users in Tab. 2. Notably, CODER is able to achieve even greater performance improvement over the baseline models.It can be attributed to the following aspects: 1) CODER learns more accurate representations by fusing the fine-grained semantics of project files with their interacted users, which facilitates the learning of user preferences even in the absence of dense user interactions.2) By explicitly modeling multiple types of projectlevel behaviors, CODER effectively models the users' interests to complement the sparse file-level contribution relations, which is more effective than encoding the project-level interactions in the embedding space.During evaluation, we rank the interactions in projects each user has not yet interacted with in the training set.This setting is considerably more challenging than intra-project recommendation since the candidate item pool is significantly larger.According to the results in Fig. 4, CODER consistently achieves superior performance by a large margin with respect to the baselines, especially for  ≥ 20.The results show that CODER jointly learns interproject differences to choose the correct repositories and characterize intra-project distinctions to recommend the correct files within the chosen repositories.

Ablation
Studies.In Fig. 3, we compare the performance of our model (abbreviated as CD) among its 5 variants.CD-F removes the code-user modality fusion strategy in Eq. (1).CD-C excludes the structural contrastive learning objective in Eqs.(22,23).CD-E does not use the pretrained CodeBERT embeddings and instead applies TF-IDF encoding on the source code, a common approach in project recommendation models [62].CD-P removes the projectlevel aggregation in Sec.3.2.2.CD-S disables the structural-level aggregation in Sec.3.1.2.Results on the ML dataset are in Fig. 3.
We observe that all 6 variants of CODER outperform NCL, among which the full model (CD) performs the best, indicating the importance of each component in our model design.The performance drops most significantly when we disable project-level aggregation in CD-P, indicating the importance of explicitly modeling user-project interactions through graph structures.We also observe a considerable decrease when we remove the structurallevel aggregation (CD-S), implying that the structural information of files has a significant contribution towards the file representation.CD-E does not lead to a more significant performance decrease, but is outperformed by CD-F where fine-grained code representations are present.Thus, user behaviors and project structural clues are more important than semantic features in code recommendation.

RELATED WORK 5.1 Research in Open Source Code
Open sourcing has grown into a standard practice for software engineering [23] and attract researchers to study social coding [70].Analytical studies focus on users' motivation [10,67], expertise [50], collaboration patterns [38], and factors that impact the popularity [2] of projects.Methodological studies explore project classification [74] and code search [33], connecting publications with projects [45].Recently, the field of Neural Code Intelligence (NCI), which uses deep learning techniques to tackle analytical tasks on source code, has emerged as a promising direction to improve programming efficiency and reducing human errors within the software industry [64].Although previous works explored the recommendation task in OSS development settings such as automatic suggestions of API function calls [20,40], Good First Issues [1,60], and data preparation steps [65], no previous works have studied the challenging task of code recommendation task, which requires in-depth understanding of diverse user-item interactions and OSS projects written in multiple programming languages.

Recommender Systems
The advances in deep learning greatly facilitate the evolution of recommender systems [3,17,41,44,72,73].Motivated by the success of Graph Neural Networks (GNN) [9,34,52,75,76,80,81], a series of graph-based recommender systems [29,55,59] are proposed, which organize user behaviors into heterogeneous interaction graphs.These methods formulate item recommendation as link prediction or representation learning tasks [46,54,77], and utilize high-order relationships to infer user preferences, item attributes, and collaborative filtering signals [45,58,68].Noticeably, traditional recommendation models cannot be easily transferred to code recommendation as they do not model unique signals in OSS development, such as project hierarchies and code semantics.

CONCLUSION AND FUTURE WORKS
We are the first to formulate the task of code recommendation for open source developers.We propose CODER, a code recommendation model for open source projects written in diverse languages.Currently, our approach only considers recommending existing files to users.As CODER harnesses the metadata and semantic features of files, it cannot deal with users creating new files where such information of the candidate files is absent.We plan to generalize our framework by allowing users to initialize files under their interested subdirectories.Moreover, our source code encoding scheme can be further improved by harnessing knowledge about programming languages such as using Abstract Syntax Tree (AST) [39] and data flow [15,20] (graphs that represent dependency relation between variables).Our current encoding scheme is a computationally efficient way to deal with the diversity of programming languages.In the future, we plan to incorporate such domain knowledge to improve the file representations at a finer granularity.Our current encoding scheme is a computationally efficient way to deal with the diversity of programming languages.Moreover, the user representations can be further enhanced by modeling users' social relations [6,36] and behaviors [25,63,66].

A DATASETS
We categorized the open source projects in our dataset using their GitHub topics.The topics used in each dataset are shown in Tab. 4.

B IMPLEMENTATION DETAILS
To derive C in Sec.3.1.1,we first convert the source code into a set of tokens, then partition them into code segments with equal number of tokens.As the source code is first tokenized and then partitioned at the token level, our partitioning scheme will not partition meaningful tokens in the middle.For example, if "def" is a meaningful token, our method will make sure that the token will not be split into multiple parts such as "de" and "f".Next, we encode the tokens using CodeBERT.Each token produces a token-level representation.For each code segment   , we perform max pooling on all of its token representations to derive c  .We use CodeBERT to encode files written in all programming languages (PL) as well as natural language (NL), as CodeBERT is able to generalize to a wide range of programming languages and shows outstanding performances on NL-PL tasks.As CodeBERT learns general-purpose code representations for both natural language (NL) and programming languages (PL), CodeBERT is suitable for encoding the rich natural language clues in OSS projects including the README file, which contains frequent context-switching between NL and PL.

Figure 1 :
Figure 1: An example of the transformers repository.OSS projects under similar topics usually adopt similar naming conventions and file structures, which can be seen as knowledge transferable across projects.
H Z 7 n O L g = = < / l a t e x i t > A : < l a t e x i t s h a 1 _ b a s e 6 4 = " b V + 1 l j D B b 0 c 8 l P z q C z T k 0 E o 1 J P o = " > A A A C l n i c b V F b a x N B F J 5 s v b T x 1 t a X g i + L Q a g i Y V e s + l C k U E V f x I h N W 8 g u 4 c z k J B 0 7 O 7 P M n E 0 b h v 0 J f d X f 5 r 9 x N g 1 i U g 8 M f P O d 2 3 f O 4 a W S j p L k d y t a u 3 X 7 z t 3 1 j f a 9 + w 8 e P t r c 2 j 5 2 p r I C + 8 I o Y 0 8 5 O F R S Y 5 8 k K T w t L U L B F Z 7 w 8 8 P

9 < 8 <
6 l X 0 6 n Y D n P v c Y L u p w r X c r n R f h / w L A 0 i 1 + C 9 2 u J F s j Y F z 4 T R o e T 1 D 5 z A h R y c + n T e p B 2 9 3 K f 7 W Z l k K k U q u x 5 X b f b 4 W D p 6 n l u g u N X 3 f R N d + / b 6 8 7 B / u J 0 6 + w J e 8 p 2 W c r e s g P 2 m f V Y n w k 2 Y V f s J / s V 7 U T v o 4 / R p + v Q q L X I e c y W L O r 9 A W 5 R z j E = < / l a t e x i t > E l a t e x i t s h a 1 _ b a s e 6 4 = " 4 F o x P 9 u J J U a G u A U E u q e m 9 o r V g 5 4= " > A A A C l n i c b V F d a x N B F J 2 s V W v 8 a G t f B F 8 W g 1 B F w q 5 Y 9 U F K Q Y t 9 K Y 3 Y t I X s E u 5 M b t K h s z P L z N 3 Y M O x P 8 F V / m / + m s 2 k Q k 3 p h 4 M y 5 X + f e y 0 s l H S X J n 1 Z 0 Z + 3 u v f v r D 9 o P H z 1 + s r G 5 9 f T U m c o K 7 A u j j D 3 n 4 F B J j X 2 S p P C 8 t A g F V 3 j G L z 8 3 / r M p W i e N P q F Z i X k B E y 3 H U g A F 6 r s Y y u F m J + k m c 4 t v g 3 Q B O m x h v e F W q 8 5 G R l Q F a h I K n B u k S U m 5 B 0 t S K K z b W e W w B H E J E x w E q K F A l / u 5 1 j p + G Z h R P D Y 2 P E 3 x n P 0 3 w 0 P h 3 K z g I b I A u n C r v o b 8 n 2 9 Q 0 f h j 7 q U u K 0 I t b h q N K x W T i Z v B 4 5 G 0 K E j N A g B h Z d A a i w u w I C i s Z 6 n S S Z r 7 R l x T Z q m 9 k h z D k H p l x r / 0 m + k U L O e 5 1 / i D r u Z K l / J 5 E f 5 f M C z N 4 l H w H p d o g Y x 9 7 T N h d D h J 7 T M n Q C E 3 V z 6 t B 2 l 3 N / f Z T l Y G m U q h y l 7 Vd b s d D p a u n u c 2 O H 3 b T d 9 3 d 7 + 9 6 + x / W p x u n T 1 n L 9 g O S 9 k H t s 8 O W Y / 1 m W A T 9 p P 9 Y r + j Z 9 F e d B B 9 v Q m N W o u c b b Z k U e 8 a Q m v O H Q = = < / l a t e x i t > 2 l a t e x i t s h a 1 _ b a s e 6 4 = " i f 7 u x 1 t y C 7 a W p y M S u m U W v 1 k x H 8 4 = " > A A A C l n i c b V F d a x N B F J 2 s V W v 8 a G t f B F 8 W g 1 B F w q 5 Y 9 U F K Q Y t 9 K Y 3 Y t I X s E u 5 M b t K h s z P L z N 3 Y M O x P 8 F V / m / + m s 2 k Q k 3 p h 4 M y 5 X + f e y 0 s l H S X J n 1 Z 0 Z + 3 u v f v r D 9 o P H z 1 + s r G 5 9 f T U m c o K 7 A u j j D 3 n 4 F B J j X 2 S p P C 8 t A g F V 3 j G L z 8 3 / r M p W i e N P q F Z i X k B E y 3 H U g A F 6 n s 1 l M P N T t J N 5 h b f B u k C d N j C e s O t V p 2 N j K g K 1 C Q U O D d I k 5 J y D 5 a k U F i 3 s 8 p h C e I S J j g I U E O B L v d z r X X 8 M j C j e G x s e J r i O

8 <
a x a P g P S 7 R A h n 7 2 m f C 6 H C S 2 m d O g E J u r n x a D 9 L u b u 6 z n a w M M p V C l b 2 q 6 3 Y 7 H C x d P c 9 t c P q 2 m 7 7 v 7 n 5 7 1 9 n / t D j d O n v O X r A d l r I P b J 8 d s h 7 r M 8 E m 7 C f 7 x X 5 H z 6 K 9 6 C D 6 e h M a t R Y 5 2 2 z J o t 4 1 a e / O L w = = < / l a t e x i t > D l a t e x i t s h a 1 _ b a s e 6 4 = " 3 Lc V v z 3 K N H + w k m a W o S b 6 L v l D C h w = " > A A A C l n i c b V F b a x N B F J 6 s t x o v b f V F 8 G U x C F U k 7 I h V H 0 Q K K v o i R m z a Q n Y J Z y Y n 6 d D Z m W X m b G w Y 9 i f 4 q r / N f + N s G s S kH h j 4 5 j u 3 7 5 w j K q 0 8 Z d n v T n L l 6 r X r N 7 Z u d m / d v n N 3 e 2 f 3 3 p G 3 t Z M 4 l F Z b d y L A o 1 Y G h 6 R I 4 0 n l E E q h 8 V i c v W v 9 x 3 N 0 X l l z S I s K i x J m R k 2 V B I r U N z n m 4 5 1 e 1 s + W l l 4 G f A V 6 b G W D 8 W 6 n y S d W 1 i U a k h q 8 H / G s o i K A I y U 1 N t 2 8 9 l i B P I M Z j i I 0 U K I v w l J r k z 6 O z C S d W h e f o X T J / p s R o P R + U Y o Y W Q K d + k 1 f S / 7 P N 6 p p + r o I y l Q 1 o Z E X j a a 1 T s m m 7 e D p R D m U

6 e p 7 b 4 G
S n m 7 7 v 7 v 5 4 1 9 n / t D j d O n v B X r J t l r I P b J 8 d s h 7 r M 8 E m 7 B f 7 z f 5 E z 6 O 9 6 C D 6 e h 0 a t R Y 5 W 2 z J o t 4 V y g z N 5 g = = < / l a t e x i t > < l a t e x i t s h a 1 _ b a s e 6 4 = " c A 2 D I M u N H x a 8 V U c a 2 L A I d 6 Y X C N H h j 4 5 j u 3 7 5 w j K q 0 8 Z d n v T n L l 6 r X r N 7 Z u d m / d v n N 3 e 2 f 3 3 p G 3 t Z M 4 l F Z b d y L A o 1 Y G h 6 R I 4 0 n l E E q h 8 V i c v W v 9 x 3 N 0 X l l z S I s K i x J m R k 2 V B I r U N z f m 4 5 1 e 1 s + W l l 4 G f A V 6 b G W D 8 W 6 n y S d W 1 i U a k h q 8 H / G s o i K A I y U 1 N t 2 8 9 l i B P I M Z j i I 0 U K I v w l J r k z 6 O z C S d W h e f o X T J / p s R o P R + U Y o Y W Q K d + k 1 f S / 7 P N 6 p p + r o I y l Q 1 o Z E X j a a 1 T s m m 7 e D p R D m U

1 <
8 x L s 3 h 5 + j 9 U q E D s u 5 p y K U 1 8 S R N y L 0 E j c K e B 9 6 M e H + / C P l e X k W Z W q P O n z R N t x s P x j f P c x k c P e / z l / 3 9 r y 9 6 B 2 9 W p 9 t i D 9 k j t s c 4 e 8 U O 2 C c 2 Y E M m 2 Y z 9 Y D / Z r + R B 8 j b 5 k H y 8 C E 0 6 q 5 z 7 b M 2 S w R / x k s 3 4 < / l a t e x i t > E l a t e x i t s h a 1 _ b a s e 6 4 = " R x 2 b S G 7 h D u T m 3 T o 7 M w y c z c 2 D P s T f N X f 5 r 9 x N g 1 i U i 8 M n D n 3 6 9 x 7 e a m k o y T 5 3 Y r W 1 m / d 3 t i 8 0 7 5 7 7 / 6 D h 1 v b j 0 6 d q a

1 <
f 5 y / 7 + 1 x e 9 g z e r 0 2 2 x h + w R 2 2 O c v W I H 7 B M b s C G T b M Z + s J / s V / I g e Z t 8 S D 5 e h C a d V c 5 9 t m b J 4 A / v Y M 3 3 < / l a t e x i t > D l a t e x i t s h a 1 _ b a s e 6 4 = " n V z 3 g + 5 d B D 3 1 + U D e n X / d z 9 5 r R h

1 <
a 5 n r d I h L 0 I r r i 2 z 1 l 4 r g X F I s z H j X / r Z f A 5 O i C I Y / E 7 n S 6 V r + a K M / / c Y l + b w c / R + q d A B W f c 0 5 N K a e J I m 5 F 6 C R m H P A 2 9 G v L 9 f h H w v r 6 J M r V H n T 5 q m 2 4 0 H 4 5 v n u Q y O n v f 5 y / 7 + 1 x e 9 g z e r 0 2 2 x h + w R 2 2 O c v W I H 7 B M b s C G T b M Z + s J / s V / I g e Z t 8 S D 5 e h C a d V c 5 9 t m b J 4 A / v Y M 3 3 < / l a t e x i t > D l a t e x i t s h a 1 _ b a s e 6 4 = " Y P x h / s 9 7 F / D T M w u t o y o m R V l 9 5 z M

1 <
8 x L s 3 h 5 + j 9 U q E D s u 5 p y K U 1 8 S R N y L 0 E j c K e B 9 6 M e H + / C P l e X k W Z W q P O n z R N t x s P x j f P c x k c P e / z l / 3 9 r y 9 6 B 2 9 W p 9 t i D 9 k j t s c 4 e 8 U O 2 C c 2 Y E M m 2 Y z 9 Y D / Z r + R B 8 j b 5 k H y 8 C E 0 6 q 5 z 7 b M 2 S w R / x k s 3 4 < / l a t e x i t > E l a t e x i t s h a 1 _ b a s e 6 4 = " 0 z S 7 r 3 q O 7 W i Z 4 / s 5 z 8 Y s o Y A D

2 <
6 e p 7 b 4 G S n m 7 7 v 7 v 5 4 1 9 n / t D j d O n v B X r J t l r I P b J 8 d s h 7 r M 8 E m 7 B f 7 z f 5 E z 6 O 9 6 C D 6 e h 0 a t R Y 5 W 2 z J o t 4 V 6 v r N 9 Q = = < / l a t e x i t > A l a t e x i t s h a 1 _ b a s e 6 4 = " R x 1 H j 5 8 8 f b a 6 9 v z I m d o K H A i j j D 3 m 4 F B J j Q O S p P C 4 s g g l V z j k 5 1 9 a/ 3 C C 1 k m j D 2 l a Y V 7 C q Z a F F E C B + p m V Q G e 8 8 L v N y W o v 6 S c z i 2 + D d A 5 6 b G 4 H J 2 u d J h s b U Z e o S S h w b p Q m F e U e L E m h s O l m t c M K x D m c 4 i h A D S W 6 3 M 8 k N / F G Y M Z x Y W x 4 m u I Z + 2 + G h 9 K 5 a c l D Z C v R L f t a 8 n + + U U 3 F p 9 x L X d W E W l w 3 K m o V k 4 n b + e O x t C h I T Q M A Y W X Q G o s z s C A o b G m h 0 m G a + 1 Z c W 2 a h v Z I c w 5 B 6 a c Y b + u 1 k A p b z 3 G v 8 R R c z p Q v 5 v A z / r x i W Z v F 7 8 O 5 X a I G M f e M z Y X S 4 T O M z J 0 A h N x c + b U Z p f y v 3 2 W Z W B Z l K o cp e N 0 2 3 G w 6 W L p / n N j h 6 1 0 8 / 9 L d + v O 9 t f 5 6 f b o W 9 Z K / Y J k v Z R 7 b N d t g B G z D B N P v N / r C / 0 X r 0 L d q N 9 q 5 D o 8 4 8 5 w V b s G h 4 B b Q 8 0 U o = < / l a t e x i t > L < l a t e x i t s h a 1 _ b a s e 6 4 = " 8 M L 7 z f X P + W S W F x S T 5 1 Y l u 3 L x 1 + 8 7 W 3 e 6 9 + w 8 e P u p t P z 6 1 u j Y c R l x L b c 4 Z t S C F g h E K l H B e G a A l k 3 D G L g 8 b / W w O x g q t T n B Z Q V 7 S C y U K w S k G a t J L s p L i j B V u 5 t 8 V k w x h g Y 5 r i u g H r R O U Q 7 / 7 B x 7 7 n U m v n w y T 1 u L r I F 2 B P l n Z 0 W S 7 4 7 O p 5 n U J C r m k 1 o 7 T p M L c U Y O C S / D d r L Z Q U X 5 J L 2 A c o K I l 2 N y 1 o / n 4 e W C m c a F N e A r j l v 0 3 w t H S 2 m X J w s 9 m E L u p N e T / t HG N x Z v c C V X V C I p f F S p q G a O O m z 3 F U 2 G A o 1 w G Q L k R o d e Y z 6 i h H M M 2 1 z K d p L l r m m v S r J W X g k E Y U m 3 M + J f e n c + p Y S x 3 C r 7 g o u 1 0 L Z 6 V w X 8 P Y W k G P g X 1 c w W G o j Y v X M a 1 C h f 0 L r O c S m B 6 4 V I / T o f 7 u c s G W R X a l B J k t u N 9 t x s O l m 6 e 5 z o 4 3 R u m r 4 b 7 x y / 7 B 2 9 X p 9 s i T 8 k z M i A p e U 0 O y E d y R E a E k 2 / k O / l B f k Y f o j L C a H 7 1 N e q s Y p 6 Q N Y u + / g a 6 + O I c < / l a t e x i t > h = 5 coatt (C, Q) < l a t e x i t s h a 1 _ b a s e 6 4 = " v X o Y l 4 8 z B 1 3 M r N T r 4 / 7 h u F i 1 r t M = " > A A A C w 3 i c b V H d a h Q x F M 6 O f 3 X 9 2 + q l N 4 O L U E W G S b H q h Y W C C t6 o L X T b w s w 4 J N k z b d h M M i a Z t U v I W / g 0 3 u p L + D Z m p q u 4 W w 8 E v n z n 7 z v n 0 E Z w Y 9 P 0 1 y C 6 c v X a 9 R s b N 4 e 3 b t + 5 e 2 + 0 e f / I q F Y z m D A l l D 6 h x I D g E i a W W w E n j Q Z S U w H H d P a m 8 x / P Q R u u 5 K F d N F D U 5 F T y i j N i A 1 W O k r w m 9 o x W 7 s D v Z n / w F 1 / y o n R 8 F / v P 7 m P Z 0 7 o O I b 4 c j d M k 7 S 2 + D P A S j N H S 9 s v N g c + n i r U 1 S M s E M S b D a W M L R 7 T l T I A f 5 q 2 B h r A Z O Y U s Q E l q M I X r B / P x 4 8 B M 4 0 r p 8 K S N e / b f D E d q Y x Y 1 D Z G d R r P u 6 8 j / + b L W V q 8 K x 2 X T W p D s o l H V i t i q u N t S P O U a m B W L A A j T P G i N 2 R n R h N m w y 5 V K h 7 h w n b i u z E p 7 w S m E I e X a j H / p Z / M 5 0 Z Q W T s J X e 9 4 r X c m n d f i / h b A 0 D R + C 9 1 M D m l i l n 7 q c K R n u 5 1 1 u G B F A 1 b n D P s P J T u H y r b w J M o U A k T / x f j g M B 8 P r 5 7 k M j r Y T / C L Z O X g + 3 n u 9 P N 0 G e o g e o S 2 E 0 U u 0 h 9 6 j f T R B D H 1 D 3 9 E P 9 D N 6 F 8 0 i H d m L 0

8 < 8 <
j s M 5 x s F y 7 f y p s g U w g Q + T P v h 8 N w M L x + n q v g + G W C d 5 L t z 6 / G + 2 + W p 9 t A j 9 E T t I U w 2 k X 7 6 D 0 6 R B P E 0 D f 0 H f 1 A P 6 N 3 0 S z S k b 0 M j Q b L n E d o x S L / G x / j 4 R E = < / l a t e x i t > C = [c 8 ] #C 8=1 < l a t e x i t s h a 1 _ b a s e 6 4 = " n p j 8 k i v y K A d t g u v 3 7 H b V V c 8 u U 7 8 = " > AA A C q 3 i c b V H L b h M x F H W G V w m v F C Q 2 b E Z E S A W V a A b R l g W L S r B g g y i i a S v i I b K d O 6 1 V j z 2 y 7 4 Q E 4 5 9 h C z / E 3 + B J I 0 R S r m T p + J z 7 v r x W 0 m G W / e 4 k V 6 5 e u 3 5 j 4 2 b 3 1 u 0 7 d + / 1 N u 8 f O d N Y A U N h l L E n n D l Q U s M Q J S o 4 q S 2 w i i s 4 5 u d v W v 1 4 C t Z J o w 9 x X k N R s V M t S y k Y R m r c e 0 g R Z s h L / y 2 M P W 7 L 8 I U 6 Z H b c 6 2 e D b G H p Z Z A v Q Z 8 s 7 W C 8 2 Q l 0 Y k R T g U a h m H O j P K u x 8 M y i F A p C l z Y O a i b O 2 S m M I t S s A l f 4 x Q A h f R K Z S V o a G 5 / G d M H + G + F Z 5 d y 8 4 t G z Y n j m 1 r W W / J 8 2 a r B 8 V X i p 6 w Z B i 4 t C Z a N S N G m 7 j X Q i L Q h U 8 w i Y s D L 2 m o o z Z p n A u L O V T I d 5 4 d v m 2 j Q r 5 Z X k E I f U a z P + p b e n U 2 Y 5 L 7 y G r z h b d L o S z 6 v 4 f w t x a R b e R / V D D Z a h s c 8 8 F U b H O w V P n W A K u J n 5 P I z y w U 7 h 6 R a t Y 5 t K g a J P Q + h 2 4 8 H y 9 f N c B k c v B v n u Y O f j y / 7 + 6 + X p N s g j 8 p h s k Z z s k X 3 y j h y Q I R H k O / l B f p J f y f P k U / I 5 o R e u S W c Z 8 4 C s W A J / A I U i 1 x A = < / l a t e x i t > z ¢ C,l a t e x i t s h a 1 _ b a s e 6 4 = " 3 B W w 1 9 G 9 J 3 B e Q P C y h O 9 U p S 3 F p 1 8 = " > A A A C q 3 i c b V H L b h M x F H W G V w m P p i C x Y T M i Q i q o R D O I A g s W l W D B B l F E 0 1 b E Q 2 Q 7 d 1 o r H n t k 3 w m J j H + G L f w Q f 4 M n j R B J u Z K l4 3 P u + / J a S Y d Z 9 r u T X L l 6 7 f q N r Z v d W 7 f v 3 N 3 u 7 d w 7 d q a x A o b C K G N P O X O g p I Y h S l R w W l t g F V d w w q d v W / 1 k B t Z J o 4 9 w U U N R s T M t S y k Y R m r c e 0 A R 5 s h L b 8 P Y 4 9 4 0 f K U O m R 3 3 + t k g W 1 p 6 G e Q r 0 C c r O x z v d A K d G N F U o F E o 5 t w o z 2 o s P L M o h Y L Q p Y 2 D m o k p O 4 N R h J p V 4 A q / H C C k j y M z S U t j 4 9 O Y L t l / I z y r n F t U P H p W D M / d p t a S / 9 N G D Z a v C y 9 1 3 S B o c V G o b F S K J m 2 3 k U 6 k B Y F q E Q E T V s Z e U 3 H O L B M Y d 7 a W 6 S g v f N t c m 2 a t v J I c 4 p B 6 Y 8 a / 9 N 5 s x i z n h d f w D e f L T t f i e R X / 7 y A u z c K H q H 6 s w T I 0 9 q m n w u h 4 p + C p E 0 w B N 3 O f h 1 E + 2 C 8 8 3 a V 1 b F M p U P R J C N 1 u P F i + e Z 7 L 4 P j 5 I H 8 5 2 P / 0 o n / w Z n W 6 L f K Q P C K 7 J C e v y A F 5 T w 7 J k A j y n f w g P 8 m v 5 F n y O f m S 0 A v X p L O K u U / W L I E / d 6 j X C g = = < / l a t e x i t > r ¢ C,: < l a t e x i t s h a 1 _ b a s e 6 4 = " I 2 E l a q H s Y I w n B Q 5i m P Z k U l R V a b 0 = " > A A A C q X i c b V F L b x M x E H a W V w m v F L h x W R E h l Y e i X U R b D h w q w Y E L o p W a N i J e I t uZ b a 1 6 7 Z U 9 G x I s / x e u 8 I / 4 N 3 j T C J G U k S x 9 / u b 1 z Q y v l X S Y Z b 8 7 y b X r N 2 7 e 2 r r d v X P 3 3 v 0 H v e 2 H J 8 4 0 V s B Q G G X s i D M H S m o Y o k Q F o 9 o C q 7 i C U 3 7 x v v W f z s A 6 a f Q x L m o o K n a m Z S k F w 0 h N e o 8 p w h x 5 6 Z s w 8 T J 8 p Q 6 Z n f T 6 2 S B b W n o V 5 C v Q J y s 7 n G x 3 A p 0 a 0 V S g U S j m 3 D j P a i w 8 s y i F g t C l j Y O a i Q t 2 B u M I N a v A F X 4 p P 6 T P I j N N S 2 P j 0 5 g u 2 X 8 z P K u c W 1 Q 8 R l Y M z 9 2 m r y X / 5 x s 3 W L 4 t v N R 1 g 6 D F Z a O y U S m a t N 1 F O p U W B K p F B E x Y G b W m 4 p x Z J j B u b K 3 S c V 7 4 V l x b Z q 2 9 k h z i k H p j x r / 0 q 9 m M W c 4 L r + E b z p d K 1 / J 5 F f 8 f I C 7 N w q f o / V y D Z W j s C 0 + F 0 f F K w V M n m A J u 5 j 4 P 4 3 y w W 3 i 6 Q + s o U y l Q 9 H k I 3 W 4 8 W L 5 5 n q v g 5 P U g 3 x v s H r 3 p H 7 x b n W 6 L P C F P y Q 7 J y T 4 5 I B / J I R k S Q b 6 T H + Q n + Z W 8 T I 6 S U f L l M j T p r H I e k T V L x B / A U 9 Z X < / l a t e x i t > u ¢ l a t e x i t s h a 1 _ b a s e 6 4 = " K Y W B h C J g u 7 l s D 8 f C S r h s d k 2 + y e M = " > A A A C q X i c b V F L b x M x E H a W V w m P p s C N y 4 o I q T w U 7 S I K H D h U g g M X R C s 1 b U S 8 R L Y z 2 5 p 6 7 Z U 9 G x I s / x e u 8 I / 4 N 3 j T C J G U k S x 9 / u b 1 z Q y v l X S Y Z b 8 7 y Z W r 1 6 7 f 2

9 < 9 < 8 <
l a t e x i t s h a 1 _ b a s e 6 4 = " v 9 m 7 u T p T e P Z R z P x 3 R x V J a d l e H S w = " > AA A C o X i c b V F L b x M x E H a W R 0 t 4 t X D k s i J C a h G K d h F 9 H D h U g k M 5 V A 2 o a S v t L p H t z L a m X n t l z 4 Z E l v 8 H 1 / K v + D d 4 0 w g 1 K S N Z + v z N 6 5 s Z V k t h M U n + d K J 7 9 x 8 8 X F t / 1 H 3 8 5 O m z 5 x u b L 0 6 t b g y H I d d S m 3 N G L U i h Y I g C J Z z X B m j F J J y x q 0 + t / 2 w C x g q t T n B W Q 1 H R C y V K w S k G 6 n u O M E V W u o k f u R 9 + t N F L + s n c 4 r s g X Y A e W d h g t N n x + V j z p g K F X F J r s z S p s X D U o O A S f D d v L N S U X 9 E L y A J U t A J b u L l s H 7 8 J z D g u t Q l P Y T x n b 2 c 4 W l k 7 q 1 i I r C h e 2 l V f S / 7 P l z V Y 7 h d O q L p B U P y m U d n I G H X c 7 i A e C w M c 5 S w A y o 0 I W m N + S Q 3 l G D a 1 V O k k L V w r r i 2 z 1 F 4 K B m F I t T L j P / r d Z E I N Y 4 V T 8 B O n c 6 V L + a w K / 8 8 Q l m b g K H i P a z A U t X nr c q 5 V u I 5 3 u e V U A t N T l / o s 7 e 8 U L t / K 6 y B T S p D 5 t v f d b j h Y u n q e u + D 0 f T / d 7 e 9 8 / d A 7 + L g 4 3 T p 5 R V 6 T L Z K S P X J A D s m A D A k n h v w i 1 + R 3 1 I u + R I P o 2 0 1 o 1 F n k v C R L F m V / A c z m 0 3 g = < / l a t e x i t > v l a t e x i t s h a 1 _ b a s e 6 4 = " y A 0 y A 0 x 6 s 2 1 N k R w u s o h q b g 9 s x 6 0 = " > A A A C o X i c b V F N b x M x E H U W C i U t t I V j L y u i S g W h a L d q a Q 8 c K s G h H B A B N W 2 l 3 S W y n d n W q t d e 2 b M h k e X / w R X + F f 8 G b x o h k j K S p e c 3 X 2 9 m W C 2 F x S T 5 3 Y k e P F x 7 9 H j 9 S X d j 8 + m z r e 2 d 5 x d W N 4 b Dk G u p z R W j F q R Q M E S B E q 5 q A 7 R i E i 7 Z 7 f v W f z k B Y 4 V W 5 z i r o a j o t R K l 4 B Q D 9 S 1 H m C I r X e N H T v j R d i / p J 3 O L 7 4 N 0 A X p k Y Y P R T s f n Y 8 2 b C h R y S a 3 N 0 q T G w l G D g k vw 3 b y x U F N + S 6 8 h C 1 D R C m z h 5 r J 9 v B e Y c V x q E 5 7 C e M 7 + m + F o Z e 2 s Y i G y o n h j V 3 0 t + T 9 f 1 m B 5 U j i h 6 g Z B 8 b t G Z S N j 1 H G 7 g 3 g s D H C U s w A o N y J o j f k N N Z R j 2 N R S p f O 0 c K 2 4 t s x S e y k Y h C H V y o x / 6 T e T C T W M F U 7 B d 5 z O l S 7 l s y r 8 P 0 B Y m o F P w f u 5 B k N R m 9 c u 5 1 q F 6 3 i X W 0 4 l M D 1 1 q c / S / l H h 8 v 2 8 D j K l B J m / 8 r 7 b D Q d L V 8 9 z H 1 w c 9 N O 3 / a M v h 7 3 T d 4 v T r Z N d 8 p L s k 5 Q c k 1 N y R g Z k S D g x 5 A f 5 S X 5 F v e h j N I i + 3 o V G n U X O C 7 J k U f Y H y I D T d g = = < / l a t e x i t > u l a t e x i t s h a 1 _ b a s e 6 4 = " K E M O l F 4 8 F k 3 9 I c E W C h z P i t l E b x A = " > A A A C p n i c b V F L T x s x E H a W P m j 6 I C n H X l Z E l U I V R b s I 2 h 5 6 Q I

Figure 2 :
Figure 2: Our proposed CODER framework for code recommendation.CODER jointly considers project file structures, code semantics, and user behaviors.CODER models the microscopic file-level interactions and macroscopic project-level interactions through Multi-Behavioral Modeling, and bridges the micro/macro-scopic signals through Node Semantics Modeling.

Figure 3 :
Figure 3: Results among variants of CODER and the best baseline model NCL on the ML dataset.

4. 2 . 3
Cross-Project Recommendation.Although 91% developers in our dataset focused on 1 project throughout their development, active contributors can work on multiple projects.For these contributors, the project core team can recommend development tasks based on their development experiences in previous projects.

Table 1 :
Summary of the datasets.The second column shows the number of files with observed interactions instead of all existing files in the projects.
4.2 Performance 4.2.1 Intra-Project Recommendation.In this setting, we evaluate the model's ability to recommend development tasks under her interacted repositories.For each user   , we rank the interactions under repositories they have interacted with in the training set.

Table 3 :
File-level link prediction results for cold-start users."LGN" stands for the baseline "LightGCN".The best performance is marked in bold.The second best is underlined.

Table 4 :
GitHub topics used during the construction of each dataset.